Oh awesome! I didn't know that, and yes it helps a lot! I suppose I could compliment this with the request.is_ajax() and I'm all set.
Thanks again! Taylor On Dec 19, 5:47 am, Srdjan Popovic <[email protected]> wrote: > Taylor, > > If you are worried about POST data submitted through Ajax request > coming from another site, you should remember that browsers do not > allow XMLHttpRequest to be sent to other domains. Having said that, > you can still use the CSRF middleware for your non-Ajax requests. A > couple of paragraphs above the one you quoted you can read this: > > "The middleware tries to be smart about requests that come in via > AJAX. Many JavaScript toolkits send an "X-Requested-With: > XMLHttpRequest" HTTP header; these requests are detected and > automatically not handled by this middleware. We can do this safely > because, in the context of a browser, the header can only be added by > using XMLHttpRequest, and browsers already implement a same-domain > policy for XMLHttpRequest. (Note that this is not secure if you don't > trust content within the same domain or subdomains.)" > > This is as safe as non-SSL security can be. > > I hope this helps. > > On Dec 19, 1:17 am, Taylor <[email protected]> wrote: > > > Yay!! Now I can sleep tonight! > > > So the docs say this about the CSRF middleware: "It may still be > > possible to use the middleware, provided you can find some way to get > > the CSRF token and ensure that is included when your form is > > submitted." > > > Has anyone found that way, or can anyone point me in the right > > direction? Or do I need to figure this out myself. > > > Thanks folks! > > > Taylor > > > On Dec 18, 9:08 pm, anb <[email protected]> wrote: > > > > > Each of my views use the @login_required decorator, is there anything > > > > else I need to do to ensure that the user is logged in and active > > > > (i.e. do I need to check user.is_active)? > > > > The meaning of is_active is an application decision. It's just a field > > > on the model, you can do whatever you want with it. > > > > > As stated above, my data comes through AJAX posts made by jQuery. Is > > > > this data automatically cleaned against SQL injection? If not, is > > > > there something in Django that I can call to access its cleaning > > > > ability? Or do I have to do it myself? > > > > Whether it comes through AJAX or not doesn't matter. If you use > > > Django's ORM to do your queries, you're safe from SQL injection. > > > > > I remember reading that Django Forms (haha, I still want to call them > > > > newforms.. good times) automatically prevent cross site request > > > > forgery by including a hidden, random, token. Is there a way that I > > > > can access this ability for my own prevention? > > > > Check out the CSRF middleware. You probably want to render a token > > > into all your pages and have your AJAX requests include it. > > > > Andrew --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
