This is a much-delayed response to the issue, but I've now pushed a
patch under which your application works properly!
The solution is a little groaty, so don't look at the patch if you've
eaten recently. ;)
On 07/28/2013 06:30 PM, Daniel Patterson wrote:
Hmm.. Well it is definitely related, because if I comment out the
message-setting code, it works.
There isn't really any way to move it earlier without losing the
semantics - the handler body is:
check logged in
dml (UPDATE ...)
set message saying it was updated
if r.Continue
then redirect (url (edit_entry ...))
else redirect (url ...)
And if I comment out the third line there, everything works.
But I don't see why this should be generating a form without the right
cookie signature - because the cookie should be set in the response that
redirects, and so when the edit_entry handler is run (that generates the
form), it should have been handed the cookie. Or does `redirect` not do
a normal HTTP redirect? Because if it does, the form generation and
cookie setting should not even be in the same request.
Adam Chlipala<[email protected]> writes:
It's possible your issue is because of an Ur/Web compiler bug, but let
me explain this cookie signature checking, in case it seems clear that
your approach isn't compatible with it.
Cross-site request forgery (CSRF) attacks involve tricking users into
following links to other sites, such that processing said links remotely
causes side effects that the user wouldn't want. This is really only a
threat when the client sends some data automatically, such as a log-in
cookie. Ur/Web protects against these attacks by requiring
cryptographic signatures of all cookie values for any pages that might
both read cookies and cause persistent side effects.
It sounds like you're somehow generating a form that winds up storing a
cookie signature that is out of date. Perhaps if you move a cookie set
operation earlier, before the form is generated?
On 07/28/2013 03:56 PM, Daniel Patterson wrote:
Yeah, it does - it sets a message in a cookie to be displayed on the
next page load (across the redirect). What happens when it posts is:
update database
set message in cookie
redirect to next page to be shown
Is this not permitted? Or what part of it could be going wrong?
Adam Chlipala<[email protected]> writes:
Do you expect the application to be changing a cookie value in between
the different steps in this scenario? That's what the error message has
to do with, probably.
On 07/28/2013 03:33 PM, Daniel Patterson wrote:
I have a form that is used for editing an entry. I want to be able to
both save the entry and continue editing and also save and return to the
index. Since multiple submit buttons aren't supported (how I would
normally implement this pattern), the solution I came up with was having
a checkbox for whether to continue editing, and then just redirect back
to the editing page.
This works the first time - the entry is saved, and the edit entry page
loads again, but when I try to submit on this reloaded page, I get a
"Fatal error: Wrong cookie signature" error. The code that produces this
is at:
form: https://github.com/dbp/latinamerica/blob/master/la.ur#L236
submit: https://github.com/dbp/latinamerica/blob/master/la.ur#L309
I know it isn't as simple as I describe, because I created a minimal
example of that and it works just fine. That example is here:
https://gist.github.com/dbp/6099783
But, I'm not sure what could be causing that error, so I'm not sure how
else to approach minimizing it.
Any advice for either potential causes (to aid minimizing) or a reason /
fix for it would be great!
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
