Ajax and DjangoΒΆ
Note
This Ajax example has been written in 2006 and therefore it is slowly falling behind the technology curve. A good deal of html interaction could be done more elegantly with jquery. This would be the javascript library that I would use today (May 2008) to implement the same functionality.
Warning
Make sure to read the security notice at the end of this page.
The following is an AJAX demo developed as a means of learning about this technology. There are two versions of the demo with different javascript libraries Prototype and MochiKit. The target use case was the so called in-place-editing, creating and submitting a form without leaving the page.
AJAX calls are made for both populating and saving the text area, feedback messages are displayed while the data is being fetched and saved. In a nutshell the approach works by assigning IDs for all the HTML tags (DOM elements) that need to be interacted with. As you’ll see there are quite a few to keep track of. But once one forms a picture of what needs to be displayed at which stage, it simply becomes a matter of creating, removing hiding or showing these elements.
Files to look at:
- the main django view views.py
- the javascript actions using prototype proto-actions.js
- the javascript actions using the mochikit library mochi-actions.js
As far as this demo goes the most notable difference seems to be in the way HTML elements are generated. The prototype based approach pieces the DOM elements toghether from strings, while mochikit can generate them with functions ... (it might just also be that I was unable to discover some functionality in prototype). The MochiKit approach resulted in cleaner code ... on the other hand I did it second and by that time I already had a good sense of what I was trying to do. I’ll probably be using this latter though, one of its quite unique features (not shown here) is a logging capability that turns out to be a great timesaver.
Get the full source here: ajax-sandbox.zip To run the demo you’ll need to have django present. You may need to edit the run.bat or run.sh script files so that the django module appears in the python path.
Send feedback, comments or corrections to istvan.albert@gmail.com
cheers
Warning
Luke Plant has recently sent me the following email
On this page:
http://www.personal.psu.edu/iua1/ajax-django-sandbox.htm
the code you present has some security serious problems:
1) You use GET for saving data instead of POST. GET should never be used for requests that have side effects - see:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
2) Further, this produces a security problem. Django has plug-in protection for CSRF attacks (not yet enabled by default, but will be soon), but by design it only protects against POST requests, due to point 1). Your code would open a JSON backdoor that isn’t protected against CRSF into someone’s application that would otherwise be safe.
I know that it is only demo code, and that you don’t have any authentication at all in the example (in which case CSRF wouldn’t be a concern anyway), but demo code that encourages bad practice or leads to security vulnerabilities if it is used as a basis for people’s work is a bad idea, and at the very least it should have a big warning notice on it.
From the look of your code, once you convert it to use POST it would require some additional work to satisfy the CSRF protection (not much - you would simply have to get the csrfmiddlewaretoken and include it with the data that is submitted). For the sake of the demo, I would just convert it to POST, and add a notice that satisfying Django’s CSRF protection will require a bit of extra work.
(Due to the same origin policy, there is another way to add protection (set the ‘Content-Type’ on the request to something like ‘application/json’, and require it to be present in the Django view), but this is a bad idea if you are already using Django’s CSRF protection, I won’t bore you with the details)
Thanks for putting up the demo code, BTW,
Regards,
Luke