Hello, Christopher!
I indeed meant this "The Tomcat restart between showing and submitting
the login page is the source of the problem."
Your explanation clarifies the core of the issue well!
I'll dig into the Tomcat documentation deeper to find out how to
inject that custom login handler.
Thanks!
On Thu, May 28, 2015 at 6:49 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
> On 5/28/15 5:29 AM, Mark Thomas wrote:
>> On 28/05/2015 10:22, Leonid Rozenblyum wrote:
>>> Hello experts.
>>>
>>> We are using FormAuthenticator and face a following issue:
>>>
>>> 1) Session persistence is disabled 2) User is on login page 3)
>>> Restart Tomcat 4) User tries authentication
>>>
>>> He receives error 400 or 408.
>>>
>>> While digging deeper we discovered that in this case Tomcat
>>> validates session id and if it's old/invalid - prevents
>>> logging-in even though valid credentials are passed.
>>>
>>> We tried landingPage solution - it looks better than error
>>> 400/408 but anyway it forces user to enter credentials twice (or
>>> we don't know how to pass credentials to landingPage
>>> implicitly).
>>>
>>> We think that an improvement of user experience would be :
>>>
>>> FormAuthenticator: 255 if (session == null) { session =
>>> request.getSessionInternal(false); }
>>>
>>> ==> if (session == null) { session =
>>> request.getSessionInternal(true); }
>>>
>>> So if session is invalid or missing - simply create it.
>>>
>>> Does this idea make sense?
>>
>> No. It makes no sense at all.
>>
>>> Can we achieve the goal of not forcing user entering credentials
>>> twice without changes in Tomcat ?
>>
>> No. The credentials are stored in the session. If you restart
>> Tomcat with session persistence disabled those credentials are lost
>> and the user is going to have to re-enter them.
>
> I think the OP is saying that the credentials are only entered a
> single time. The Tomcat restart between showing and submitting the
> login page is the source of the problem.
>
> Leonid, the servlet spec is very clear about the workflow for
> authentication: the client must request a protected resource, then the
> container challenges the client for authentication (shows the login
> page), and then the client must submit valid credentials (send a
> request to j_security_check). After that, the container must
> re-process the client's original request with the newly-authenticated
> principal.
>
> Tomcat stores the original request in the session. If you lose your
> session between presenting the login page and submitting the
> credentials, Tomcat has no way to re-process the original request.
>
> IMO, this is a hole in the spec, because it doesn't allow people to
> login simply because they want to; instead, they must first attempt to
> reach a protected resource.
>
> If you want your users to be able to login without requesting a
> protected resource, you may write your own login-handler and call
> ServletRequest.login(). That way, you won't require a session to exist
> during that whole workflow.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVZzkfAAoJEBzwKT+lPKRYnxgP/jRvzmTgLbjOWErrYrKcE3M1
> n6xnW8WRws8sTUnzZpcnqsE2sFdCuUBu5PFMZHmmU4Ku8EbuwO34F2P/BsmFellZ
> flNpMBR1YEcm7BJMKRhWzpmGl9Bawa5GZaX5FLot+QvzHb7xpdQ4aI+nuy1SQM3s
> eKEDPGzdLmOCNEK/ryJnQb9d4sbZ0iH7sNbQYDU7I8jsirbvQUDGOK/TUQEhejqA
> uviUVjOWM0tvEfnbPWSNE3PQXznw3rlrOoEcixAzyF+k1w8rIoD1Kui8YvJQAWPP
> j+lakjCgIPHDCQyFJRK0ysBKH3QsPvD0RITeWiwRfWNGevqyc2fqqGvcgUOrh4+2
> sbEcZTlOk5YtLpyTzfJggANFYx72m7GOcSE+hyRJ43S83RrBYVxezUoyNfPfelLF
> UDcJt+yVxO37auIZAg4TLpiUYabHcFSmk2D1ka/8HXJO1mTiedckFzIkg2fHYL+8
> zIQG5i/L3HqMFYZ/uMThYJlIJztMVdzPTi4Uhf8AO8Cwof4ptw+Bds2Yk2K2S5UZ
> OS3Xqw0Iw6UD/jY3aT6MXm6UvsXL2MI5JBJFvUSXDaBSWTDAU1nmE7U93k/qpt5L
> ov8Bl3YLJoIj3QP1VZbPb537mAI0n4QmWRTf1+dPb0VPIt4LD5OifkuKE71aZkA/
> 8PAwsXwo1NQEqOMN4NQe
> =VRcn
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
