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(a)redhat.com
<mailto:sthorger@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(a)redhat.com
<mailto:mposolda@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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com