Re: Reloading XSRF token on browser 'back' button?

On Wed, Dec 04, 2024 at 02:00:29PM -0500, John P. Rouillard wrote:

> Question: why is she hitting the back button?
Yes, that is probably the right question to ask :-)

> If she is using a item (issue123, user2 ...) form, it should leave her
> at the same page she started on. Going back would show the same page
> but with an empty form since the form data was used to update the
> item. This issue might be resolved by changing the steps in the
> workflow.

No I think going back will still show the filled-in form.
At least on my firefox (but see below)

> >I can easily fix this by resetting the 'submitted' variable on page load
> >(which is, fortunately, also triggered on browser 'back' button).
> 
> This isn't relevant to this issue, but I have wanted the back button
> to reset after a few seconds (in cases where connectivity failed). To
> do this, I disable the button, change the text to "submitting") and
> set up a function to reset the button to a clickable state using
> setTimeout().
> 
> >But the XSRF token has already been used and we get an error on the second
> >submission.
> >Now the user can just submit again (because the page with the error now
> >has a new XSRF token) but they might give up
> 
> On load you can tell that the the form has been submitted by the
> submitted variable/button state.
[..]

Yes, I was planning to use the 'submitted' variable.

> Then you can you pop up a message:
> 
>   This page has been submitted already. For security, you need to
>   refresh the page before submitting it again. [refresh page]
> 
> where refresh page does a location.reload(). Alternatively just do the
> reload automatically under these conditions.
> >(losing all data entered into the form).

This is was I want to avoid.
As it currently stands going back does *not* lose info in the form.
And submitting gets us a CSRF message with the form fields still filled
in, so we can just submit a second time (this time we have a new csrf
token).

> Well the data has already been committed so I am not sure its loss is
> an issue. But I am not sure what the workflow is here. Also when using
> the back button, I am not sure if the data represents the current
> state on the server.

Hmm, if some fields are missing in the form the user gets an error
message on submit. I think I need to understand more about *why* they're
hitting the 'back' button.

[..]
> The CSRF nonce is unique per connection and is only supposed to be
> used when that specific page is submitted. Once it is used, a new
> valid nonce has to be minted on the server. The location.refresh()
> method should force a reload and minting of a new nonce.  This might
> wipe any locally entered data present in the page though.

I think I need to experiment with this. At least in my experiments when
we hit an error (e.g. missing title), pressing the back button has the
form still filled. But it should be unnecessary to press the back
button.

> If preserving form data on the 'back' page is required, I think you
> can store all the form data in session storage to using

Hmm, I don't think I want to go that way :-)

> [..] Some ideas are found at:
Thanks for the pointers!

> https://darekkay.com/blog/preserve-form-values/
This has a table on preserving values by several browsers, seems firefox
and chrome preserve values on 'back' and firefox even on page reload.

> Thoughts?

I think my first step is finding out why we need the back button at all.

Thanks!
Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]