+1 to restart the flow entirely when back button is pressed in any stage
(either authenticator or required actions screen). Or maybe even drop
the ClientSession entirely and redirect back to the application?
Once we use this "must-revalidate" header, I hope we can detect that
request was triggered by back button. Maybe we will need to maintain all
previously used action keys on ClientSessionModel, so we are clearly
able to detect that request was triggered by back button?
Note that I am not usability expert and I am not sure what is best
practice regarding back button and usability. But redirect back to the
application looks like most clear way to me.
Marek
On 26/01/16 23:36, Bill Burke wrote:
The current thinking for browser back button is to set:
Cache-Control: no-store, must-revalidate, max-age=0
There are possible security issues with this that I don't know if we
should do this or not. Don't know if you remember how ClientSessionCode
works, it uses a hash of the client session id and the action key
currently stored in the. When you switch from authentication to
required actions, the action key changes. Now, if you hit the back
button on a required action page, it would take you back to an
authentication screen. The code check would fail because the action
keys don't match.
Do we actually need this action key stuff? Can we just let the flow
manager put the browser in the correct state? So if an "authenticate"
url is hit and the flow is on required actions, just redirect to the
required actions URL. I just worry that this is some sort of security
hole somehow. Maybe we're better off just reseting and restarting the
flow entirely.