[keycloak-dev] advice on back button

Marek Posolda mposolda at redhat.com
Wed Jan 27 09:44:20 EST 2016


Just checked how Facebook works. If you login and then press "back" 
button on consent screen, they also just redisplay this screen. The 
thing is, that with this behaviour when you press "back" button 10 
times, you're still on the same page. Doesn't seem to be a way to go 
through browser history back to the application or even earlier.

Not sure if this is a problem or not. I am personally almost don't use 
back-button (especially on stateful sites where I am logged) as many 
sites are broken and I never know what the back button will do ;-)

Marek

On 27/01/16 15:20, Bill Burke wrote:
> Lol, we used to have "back to app" button, removed it.  we still have 
> a cancel button on OTP page, this just restarts the flow. IMO, if 
> users want a "back to app" button, they should just add it themselves.
>
> On 1/27/2016 3:58 AM, Stian Thorgersen wrote:
>> The back button should just re-display the current page. Then there 
>> should be separate link/button on the page to go back to the 
>> application (as long as base url is set on client this should always 
>> be available, even if client session has timed out). I think we 
>> should also consider having a button/link to restart the flow.
>>
>> On 27 January 2016 at 09:55, Stian Thorgersen <sthorger at redhat.com 
>> <mailto:sthorger at redhat.com>> wrote:
>>
>>     The action key was introduced in the whole days when we didn't
>>     have any state on the server that was aware where the flow was.
>>     Now that we have a clear state on the server that is fully aware
>>     of where in a flow a user is it shouldn't be required any more,
>>     and as long as the flow manager puts it in the correct state
>>     there's nothing that a user can do to try to jump back/forward in
>>     the flow.
>>
>>     On 27 January 2016 at 08:11, Marek Posolda <mposolda at redhat.com>
>>     wrote:
>>
>>         +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.
>>         >
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160127/9a38a57f/attachment.html 


More information about the keycloak-dev mailing list