Re: FormAuthenticator, Tomcat restart
Thank you, Christopher!
On Thu, Jun 11, 2015 at 4:34 PM, Christopher Schultz
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
>> 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
> FzTTDDkMRuZG2
Re: FormAuthenticator, Tomcat restart
-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
> 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: user
Re: FormAuthenticator, Tomcat restart
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
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
Re: FormAuthenticator, Tomcat restart
On Fri, May 29, 2015 at 9:47 AM, André Warnier wrote: > 20-odd Well the development team uses Tomcat via Eclipse and after changing some code they do Tomcat restart because more often than not, hot redeploy doesn't give good results. That's why Tomcat restart is a RATHER often event during the development (maybe we're doing something wrong that's why hot redeploy doesn't work as expected). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FormAuthenticator, Tomcat restart
Leonid Rozenblyum wrote:
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
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
It all begs the question, by pure curiosity if nothing else, of how often the OP restarts
his Tomcat, that this issue seems to bother him so.
Last time I looked, my 20-odd Tomcats had been running for some 240 days or so.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FormAuthenticator, Tomcat restart
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
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
Re: FormAuthenticator, Tomcat restart
-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
Re: FormAuthenticator, Tomcat restart
The reason is :
After Tomcat restart, and logging-in browser provides an old session
id to server.
FormAuthenticator treats it as an issue, and either sends error or landing page.
On Thu, May 28, 2015 at 12:30 PM, Leonid Rozenblyum
wrote:
> Well the issue is that if user enters CORRECT credentials AFTER Tomcat restart
> he sees Error 400/408
>
> On Thu, May 28, 2015 at 12:29 PM, 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.
>>
>> Mark
>>
>>
>> -
>> 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
Re: FormAuthenticator, Tomcat restart
Well the issue is that if user enters CORRECT credentials AFTER Tomcat restart
he sees Error 400/408
On Thu, May 28, 2015 at 12:29 PM, 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.
>
> Mark
>
>
> -
> 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
Re: FormAuthenticator, Tomcat restart
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.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
