Hello.
Just to double-check.
By writing own login-handler, do you mean, overriding
FormAuthenticator.authenticate() (looks risky since it's a big method
which can change from one to another Tomcat version)?
Or are there more painless ways to inject such custom login handler?
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
