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
