Re: FormAuthenticator, Tomcat restart
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:
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
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
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
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
Re: FormAuthenticator, Tomcat restart
On Fri, May 29, 2015 at 9:47 AM, André Warnier a...@ice-sa.com 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
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
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
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
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: [OT] FormAuthenticator, Tomcat restart
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 5/29/15 2:47 AM, André Warnier wrote:
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
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
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.
... then they are overdue for an upgrade ;)
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJVaLlQAAoJEBzwKT+lPKRYOewP/3lqUehWgT5s6SjDVRw/sxtS
SbCUGEL5UrRjUnTZ9v9emsUFsq6ZO/agXJ6c2sgcJQW/MIC4rprvndvh7r+aSTs6
68H25F037Lg9GyNe9qZVCg49MMPF4BBfuIOfSRkP2uEZ0lIxge0tE54+rqlcZgvK
jx5A1A71aEg58tbJeaeCUiRrXdlznlajwcUEl6n5KR6YKNntVax/TeJ68Y9/RA6l
yT2E+9EarNeTaQ8MdkihUb9g7t9z7x4IzkA3RCa5ZQ7FicAzX3A0AC3Rd4Wi/eI2
I7CmPcV7CHtPuuVfAyeqEtOU2QRzPZb4GDt8rGDvwT8H7tsXBf+YpyIK+vEYcC/u
U0dRq0/9dtUCJhxYIIyub8wrLB5XIVIAVN1KvI+Vis27oXMPp+OwLVsVCy4p6WEP
HK/I3faqIspw5lRBB3TIMA7s7jWliai/G1vC/koIuNBNL5wbOcmsDKDKd1sfkbpq
ZfT5uRdfBdKdRYTkpoupOScgLBuhb6LW7U75nvmaN5T0Uk5eEwU1+OC2LCwK42bJ
CCtY59qUz/5G+mvgDIODipQuOZxmk2mz67lvRheASskD58zUrk0F7OAeVB9KBIUR
ahD6fANtAmR5TINj+ZZI7yvjxl1jqwE3fzl4QwfLOx9ZbBCH9Ic8y3iqRk4mUgEq
ZR2bLVBn3SIePIT5HLar
=xXzw
-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
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
FormAuthenticator, Tomcat restart
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?
Can we achieve the goal of not forcing user entering credentials twice
without changes in Tomcat ?
Thanks in advance!
-
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 ma...@apache.org 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
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
lrozenbl...@gmail.com 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 ma...@apache.org 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
-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
