I was taking about case #2. Cheers Ian.
On 11/4/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Ian, > > > by doing this you would disable/stop post's coming from via > > javascript/ajax method. > > it wouldn't be able to access the tokens required, or at the very > > least it would require a form tag to be someone on the HTML page which > > is generating the post (which might not be the case) > > I'm not quite sure I understand. A post done via javascript should > work, as the form field is indeed on the page, and should be included > in any submission. Are you talking about forms that are dynamically > generated somewhere? In that case: > > 1) if the form is created server side and is returned as > application/xml, the CsrfMiddleware won't modify it. I could add some > public method to the CsrfMiddleware module to get the token (it needs > just the session ID passed in), which could then be manually added to > the form. There is a corner case here when the session cookie is > first set, which is done by the Session middleware after the response > is returned, and so the session ID wouldn't be available to the view. > (the middleware can currently handle this if it processes the response > after the session middleware, which is why it must come before the > session middleware in the list). It may be that this wouldn't be a > problem with the app, it depends how it works. > > 2) if the form is created client side, you have a problem. One > solution might be to add a setting for the CsrfMiddleware to allow it > to ignore certain paths, which you would use for your AJAX postbacks, > and you would then have add your own protection against CSRF for these > requests. > > Luke > > -- [EMAIL PROTECTED] -- ++61-3-9877-0909 If everything seems under control, you're not going fast enough. - Mario Andretti
