Thank you, Christopher!
On Thu, Jun 11, 2015 at 4:34 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Leonid,
>
> On 6/11/15 4:18 AM, Leonid Rozenblyum wrote:
>> 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: 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
>
> No, I was suggesting that you write your own servlet or filter that
> handles your logins. Instead of pointing your login form at
> /j_security_check, you point it at /your/login/servlet and then call
> Request.login() yourself. That way, you can decide what to do if the
> session has timed-out in the meantime.
>
> Note that you are opening-up a large can of worms by doing this. You
> will be introducing lots of other problems that you will have to solve.
>
> You might want to check out securityfilter, a project that is quite
> long in the tooth, but somewhat gracefully handles situations like
> this. It has its own set of awkward things you'll have to deal with
> (like not being able to authenticate against Tomcat's realms, for
> instance).
>
> [One of these days, I'm going to get off my butt and update that project
> .]
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJVeY5OAAoJEBzwKT+lPKRYdpkQAJ4BGgPNJWU34mAKo0YljHBN
> rAeIjl4gn4k+xU7mHwWH3h45hgCQVh+iCkqjH7rbgeGI1/IqETJcK2lXoXk/B+ZY
> VjmMjh+fqRsUZG/UoP2T3cvrqCs0tl1Sm17WzJOLePYNNuowQVbmFznl4GAVoKsI
> yRFYz7fPD4nXiS7+endkdVPGEn1sYSCQP5+EyVUNIlvqwOb9PN3bAlDSczidVHCN
> oDgSrOvE9SGC88igS8sLW3NiWXPYqXVeI1YiX46S5AC/1JApFPzdVhYsbgvRUegG
> k1EPo0YusG1jtBLj6fsqz6bsXZSIGchjZf2hwm/rrrpWdxJnKNAds8FRJ8Gfz43w
> uJWRXZtwpBYXdl1btBLUlCHTUTUPkQZDqcT2pktmtAK7tDCQm7BA8x4cibRwztMI
> QstMMgPjdjhS4ChuCcfEPoNzKNVDMDDH4pdjHj8hXE/b7PA7BSjRGtZIAvu0ZYZc
> RauQUnsTGMzQyNeDAZBCqMhAxQO42B82Yu0cpMTVHqRDw5uEJq2+bhgzi7slJOMO
> jLFxVT/k6DNdTG8+Z7eEfvaZXkf11o4arRGOH3gzZLtzPZgJQ3pDJ9gjKkvpcc4F
> FzTTDDkMRuZG2J8VHrAKqf2VGNcqIgmdEKPMtKde4A3xJDtv7CGZLLhksneBLLAU
> bsPyxrRr5sFycwffd/9k
> =tRmm
> -----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
