The GET response should be a JSON list of files, not a page template

[centipede]

When the fileupload widget is set up, it initially Ajax-loads what seems to be a list of files. I may have misread both yours and Tschan's code, but I think you serve the complete template page on that occasion instead.

Some info, and my apologies for giving line numbers. Not very reliable when code changes.

Loaded here:
https://github.com/miki725/Django-jQuery-File-Uploader-Integration-demo/blob/master/templates/upload.html#L62

Tschan's PHP class serves a short json list of files (not sure which ones exactly):
https://github.com/blueimp/jQuery-File-Upload/blob/master/example/upload.php#L312 i.e.
https://github.com/blueimp/jQuery-File-Upload/blob/master/example/upload.php#L234

.. But your response renders the entire html page:
https://github.com/miki725/Django-jQuery-File-Uploader-Integration-demo/blob/master/upload/views.py#L217

Regards,
Rene Jensen

[miki725]

I will look into it.

In order to implement it properly (get JSON list of previously uploaded files), the files paths must be stored in a db. With the current implementation, the file delete link includes a path to the file which I use in the script to actually delete the file. If other users will be able to get the list of previously uploaded files, that might compromise site security. So to make it work securely a db has to be used (and most likely a user authentication), which originally I did not want to do since that will complicate the demo.

[centipede]

That would be overdoing it. Simply returning an empty JSON list would be fine. I use:

else: #GET

        response = HttpResponse('[]', mimetype="application/json")
        #response.COOKIES['csrftoken'] = get_csrf_token
        return response

As you can see I'm not sure what to do with the csrf token though.

[miki725]

Once I have a chance, I will fix this. Meanwhile, to set csrf token, you don't have to do anything.

You can read more about that here.

Here are a couple of points which you might find helpful:

• CSRF is enabled if you have a middleware django.middleware.csrf.CsrfViewMiddleware enabled (which it is by default). This means that the csrf cookie is send to each view, therefore you don't explicitly have to include it a view.
• If the middleware is not enabled, you can always enable a csrf for a view by including a csrf_protect decorator.

@csrf_protect
def myview(request):
    pass

• And if you have middleware enabled but want to disable csrf for a view, you can include csrf_exempt decorator.
• When csrf is enabled for a view, it does not mean that when submitting a form from a page rendered by the view, that csrf value will be send to the server. In order to send it, you have to include {% csrf_token %} within the page template, which will create a hidden form field. Therefore the csrf value will be send to the server upon form submission, and therefore will be validated.
• If csrf value has to be send through AJAX (and you use jQuery), you can use the jQuery fix (from here), which will automatically send the csrf on each ajax request.
• If you don't use jQuery, and need to send the csrf, you then can manually read the csrf cookie value in js, or you can pass csrf value from the view to the template in the template context:

view:

def myview(request):
    t = loader.get_template("template.html")
    c = Context({})
    c.update(csrf(request))
    return HttpResponse(t.render(c))

use in template by including: {{ csrf_token }}