Possibility to restore request after CSRF problem

Maybe I should just post this as an issue, but probably this also needs a little discussion :slight_smile:

This happened to me:

I wrote a comment to a post on my mobile when suddenly my phone crashed. (This happens sometimes because my phone is broken!) So I rebooted and fortunately my browser remembered what I wrote. I was verry impressed, thank you Firefox. So I added a few sentences (and this was a little arduous since I was doing this on a broken touch-device) and I finished and sended an… meh CSRF-error I needed to login.
This totally makes sense to me! The phone crashed, the session broke so… a smarter person would have copied the comment and started over, but I wasn’t smart.

Solutions

My first idea was… after an CSRF-error and the login I would love to find myself in the same state just before I sent the comment (or whatever I wanted to do). Okay, this is pretty hard to program because you have to handle every case the user could have done an “reconstruct” it.

So maybe… just show a little form that displays the whole request (what I wrote and what target-post-id blablabla and so on) and I get the chance to send it now with a valid CSRF token. Or just dismiss it.

Or… and this might be probably the easiest way to do it: Put that data into the email. After an CSRF problem I get an email telling me there was a problem. I hope it wouldn’t be that difficult to include just the whole request in this email. With all the payload and maybe some or all metadata.
In this case I could just copy the content, fill into the comment-field I wanted to have it and send it again.
Plus: This data might help to debug the problem if you don’t know why the CSRF check failed. Is it an open tab? Is it an app or another client? Another browser? Or is it an attacker?

This last idea might have some privacy-trouble, but: If you send out an unencrypted mail from a real attacker you would expose the “private” data of the attacker not that of the user. If the data is the users data, an attacker would have to provoke an CSRF invalidation to get the data of any request via unencrypted email. I’d say this is very hard to cause. But yea okay maybe the data should only be included on public activity (I’m just afraid this makes the task harder, I hoped this could be a “newcomer”-job :D)