Hi,
On Sun, Apr 24, 2016 at 7:29 AM, Greg Wilkins <gregw_at_webtide.com> wrote:
> So the credentials have been put into request scope, so that if the
> user navigates away then they have either aborted the flow, or the
> authentication proceeded far enough that they are indeed
> authenticated.
>
> I can't see the case where they resume an attempt to login and that
> discovers any kept state, as it was put into request scope.
>
But that's not the use case ;)
The use case is when the user navigates away and explicitly wants to start
a *new* authentication dialog.
At that point there may be state lingering behind. When the application
calls request#authenticate(), the authentication mechanism doesn't know
wether it should use the state or disgard it. In this case it would be
disgard, but the authentication mechanism doesn't know that.
> Even if it is put into session scope, then it is likely to be
> overwritten with new values (Eg destination) when the authentication
> is resumed.
>
Unfortunately, this is not always so likely in general, but please note the
main use case is not {user is in dialog, user navigates away, user wants to
resume}.
There happen to be cases where the state may be overritten, such as when
the new page the user navigates to is also a protected one.
But if the user is within a dialog spanning multiple application provided
non-protected pages (say /login1, login2, /login3), and the user navigates
to another non-protected page (say /home), and clicks on "login" there,
then likely nothing has been overwritten. Since /home is indistinguishable
for the authentication mechanism from /login1, /login2, /login3.
Also note that state in general doesn't just concern the destination. In
custom multi-step dialogs it's arbitrary really.
Kind regards,
Arjan Tijms