Hi,
On Mon, Apr 25, 2016 at 12:55 AM, Greg Wilkins <gregw_at_webtide.com> wrote:
> So the use-case you are concerned about is that if a user directly
> navigates to the login form, either via a bookmark or a link from a
> not protected page in the application, then calling authenticate()
> might see some state (most specifically the original destination) from
> a previous invocation.
>
Indeed, that would be one instance of the problem.
> Well I can see that could be a problem, but I'm not sure that it is
> only related to the authenticate() method. Pure FORM authentication
> suffers from the same issue without the use of a call to authenticate.
>
True, it's not unthinkable that depending on how pure FORM is exactly
implemented a similar problem occurs there as well. (I'm not sure if the
Servlet spec says anything about directly posting the configured login page
to j_security_check without having been redirected or forwarded to it
before)
> Maybe the solution it to describe what behaviour should be when the
> login form sees a referrer field that differs from any save
> destination. If we said that if the referrer field is present, then
> it should replace any saved destination, would that fix your issue?
>
Not exactly, unfortunately, since that would (perhaps) only work for the
Servlet defined FORM. The issue I'm seeing (and actually encountered a
couple of time, among others when building zeef.com), is more general and
mostly applies to custom mechanisms.
For example, with an OAuth2 mechanism you may present a /login page letting
the user choose between providers Google, Twitter and Facebook in step 1.
This choice is put in the session. Then a timestamp is put in the session
as well (csrf protection), and the user is redirected to the provider. Then
the user arrives back at /login, and the mechanism uses its state to
determine it's a valid callback, contacts the provider back (server to
server), receives a "profile" (user data), which is put in the session
again. The mechanism may see that the profile is incomplete (e.g. no email,
like in Twitter's case), and direct the user to a form for entering the
email. If the email is entered, the user is redirected to the original
destination, where the mechanisms finds the complete profile in the session
and uses it to establish the authenticated identity, clears all state and
the dialog ends.
As you can see there's a few points where things are put in the session and
a few points where the user can navigate away.
For instance, the user can navigate away from the provider (not log in
there), or the user can be redirected back to the application's /login with
some kind of error that the application displays, and then navigate away,
or the user can navigate away when on the mentioned page for entering the
missing data (email) is presented, etc.
Fixing this with heuristics is quite difficult and error prone (we tried at
zeef.com, didn't work well), but for somewhat simpler mechanisms it indeed
may work.
Kind regards,
Arjan Tijms
>
> regards
>
>
>
>
>
>
>
>
>
>
>
> --
> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>