Dataloss with "Invalid XSRF token" error

[GoogleCodeExporter]

If you leave a review page open too long (24+ hours?) and then try to write a 
reply, after submission you get "Invalid XSRF token."  Then if you hit back, 
your reply is gone, because it was composed in some AJAXy box that no longer 
appears.

There are several possible mitigations.

First, the full submitted reply (or other mail) could be pasted on the "invalid 
xsrf token" page so you could copy it and paste it back in when going back.

Second, the page could be structured such that when you go back, the browser 
can successfully persist the relevant form data.

Third, the page could do JS requests every few hours to keep the token alive.

Original issue reported on code.google.com by pkasting@chromium.org on 12 Jan 2012 at 8:39

[GoogleCodeExporter]

You must be using Firefox, right?

Original comment by techtonik@gmail.com on 12 Jan 2012 at 8:45

[GoogleCodeExporter]

No, I'm on the Chrome team and this has bitten us for a long time.

Original comment by pkasting@chromium.org on 12 Jan 2012 at 8:47

[GoogleCodeExporter]

I believe I've fixed this for Chrome some time ago 
http://code.google.com/p/rietveld/issues/detail?id=198

Original comment by techtonik@gmail.com on 12 Jan 2012 at 8:49

[GoogleCodeExporter]

I encountered this problem yesterday using the Chrome Dev channel, so it's 
definitely not fixed.

Original comment by pkasting@chromium.org on 12 Jan 2012 at 8:54

[GoogleCodeExporter]

Can you confirm that it is the same issue as #198?
Can you write a test to repeat the issue?

I do the following (Google Chrome 17.0.963.26 beta):
1. Open http://codereview.appspot.com/5475061/
2. Hit 'Reply', enter comment 'XXX'
3. Click any link on the page to navigate away
4. Hit 'Back'
5. Hit 'Reply' again
6. Look at 'XXX'

Everything works.

Maybe there is a regression in a dev channel?
Maybe you were logged out?
Maybe there is a different problem, but we need a way to repeat this somehow.

Original comment by techtonik@gmail.com on 12 Jan 2012 at 9:01

[GoogleCodeExporter]

Your test steps work, so this is not a Dev channel-only regression.

I appeared to be logged in both before and after reproducing the problem, so I 
don't think that's it.

I explicitly tried to "reply" yesterday when this happened to me and my 
previous reply was not preserved.  So I don't think what's happening here is 
precisely the same as what happens if I navigate away via a link click.  Of 
course now you're making me second-guess myself.

It seems like this is pretty easy to check -- pull up some issue in a Chrome 
window, leave it until some time tomorrow after the token will have expired, 
click the "reply" link and write a comment, then "submit" to get the error.  
Then hit back and reply again.

I suggest both of us do this.  I'll go ahead and load up a tab now.

Original comment by pkasting@chromium.org on 12 Jan 2012 at 9:10

[GoogleCodeExporter]

I think there is a way to expire token faster from developer instance. I've 
tried: 

from codereview.models import Account
acc = Account.all().filter('email =', 'test@example.com').get()
print repr(acc.xsrf_secret)
acc.xsrf_secret = None
acc.put()

But it didn't work.

Original comment by techtonik@gmail.com on 12 Jan 2012 at 9:33

[GoogleCodeExporter]

Re: comment 6: I finally got around to retesting this.  I pulled up the link 
from comment 5, left it open in a tab well over a day, hit the "reply" button 
and deleted all the content, then hit "send message".  On getting the "invalid 
token" page I hit back, and hit "reply" again.  The boilerplate text was all 
back rather than still being deleted.

Original comment by pkasting@chromium.org on 25 Jan 2012 at 2:38

[GoogleCodeExporter]

Original comment by albrecht.andi on 6 Apr 2012 at 7:41

• Added labels: Component-Server

[GoogleCodeExporter]

This has been hitting me a bunch over the past month or so, but without leaving 
the window open for a full day.  This morning I opened up a code review, but 
did no edits.  Now [after lunch], I clicked "reply" on the last comment, typed 
for a while, submitted, got the error, and lost all my text on "back".  The 
window had been loaded for less than 4 hours.

In case it's relevant, I don't believe I needed to log in to my account while 
the window was up; I've got a cookie left over from last week.

I'm on Chrome/Linux 19.0.1084.41 beta.

Even if you can't repro/fix this, I'd love any of Peter's mitigations.  I've 
hit this at least 3 times already, and it's really a time-waster.

Original comment by ericu@chromium.org on 7 May 2012 at 9:21

[GoogleCodeExporter]

Yeah, we should rig this so that going back to the form and hitting reload 
keeps the edited text (or at least going back *without* reloading keeps it, so 
you can save it in the copy/paste buffer around a reload).  Sadly I don't know 
how to do that.

Original comment by gvanrossum@gmail.com on 7 May 2012 at 9:23

• Changed state: Accepted

[GoogleCodeExporter]

Stick the text in a field that's always present (at least in the DOM even if 
not visible, or just make it visible all the time like these comment fields on 
bugs are) and the browser will remember it for you.

Pasting the submission on the "invalid xsrf token" page would be nice too.

Original comment by pkasting@chromium.org on 7 May 2012 at 9:30

[GoogleCodeExporter]

I don't think going back without reloading doesn't work since the invalid XSRF 
token will remain in a hidden field then.

Here's a patch that at least prints out the data posted to the server: 
http://codereview.appspot.com/6190058

According to the source a single XSRF token is valid for just one hour, but we 
take the last two tokens, i.e. two hours, into account when checking if a 
received token is valid. Maybe we could increase this time span a bit. Where 
there any reasons for this two hour window?

Original comment by albrecht.andi on 8 May 2012 at 7:48

[GoogleCodeExporter]

The above mentioned change is now live. You'll now see the data posted to the 
server along with the "invalid xsrf" message.

Original comment by albrecht.andi on 8 May 2012 at 7:00

[GoogleCodeExporter]

The above mentioned change is now live. You'll now see the data posted to the 
server along with the "invalid xsrf" message.

Original comment by albrecht.andi on 8 May 2012 at 7:00

[GoogleCodeExporter]

I merged it back into the chromium branch, which was affecting the 
@chromium.org users and made it live a few days ago.

Original comment by maruel@chromium.org on 12 Jul 2012 at 2:57

• Changed state: Fixed