-----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
