On 1/12/2016 10:57 AM, Thomas Scheffler wrote:
Am 12.01.16 um 14:41 schrieb Mark Thomas:
1.) are not required as every request belonging to the same session
are
already authenticated. After login() other request of the same session
will not return 'null' on getRemoteUser() or getUserPrincipal()
2.) are not required, as authenticate() use the information
provided by
the first login() call.
3.) do not modify the session ID as the same user was authenticated
before and the session is therefor safe to session fixation attacks
Those 3 all boil down to essentially the same requirement.
Sorry, I do not see this leed to the same requirement.
1.) The Servlet-Spec notes:
13.6.3:
"The login method of the HttpServletRequest interface provides an
alternative means for an application to control the look and feel of
it’s login screens."
13.6.3.1:
"If the user is authenticated using form login and has created an HTTP
session, the timeout or invalidation of that session leads
to the user being logged out in the sense that subsequent requests must
cause the user to be re-authenticated."
This defines a call to login() should be handled like Form-Login and not
as Basic-Authentication - like Tomcat currently does. It further states
the the user is logged-out on session timeout and not with every new
request.
No it doesn't. You are reading more into the specification than is
actually there. The final sentence of 13.6.3 is there to make the reader
aware that the login() method exists as an alternative to using FORM
authentication. Nothing more.
What I read in the specification is that a *fix* could be implemented
that would a allow the bug to disappear. The third point above, changing
the sessionId only if the user is "new" to the session, would fix the
problem, could be integrated easily and would help me and possibly
others. Does it open a new security risk? No. Tracking the user
information in a session is also explicitly allowed by spec.
Requests are populated with cached authentication information from the
session at the start of the request (if the authenticator is configured
to do so - all but DIGEST are by default).
As stated above, if I use the authenticate() method. The user get a
Basic Authentication window asking for a login. At latest there should
be a usage of the already known credentials used by login().
As per the specification, calling that method is required to trigger the
same authentication process and that is exactly what happens.
The authentication process does check for cached credentials but, as
with the other authentication related calls on the request, it checks
the request not the session and the request is populated from the
session at the start of the request processing.
You are right. Again there is nothing that prevents you to help to fix
that issue, neither spec nor anything. If one uses login() on request
and during the request a session is created or already exist use the
FormAuthenticator or create a LoginAuthenticator class instead of
BasicAuthenticator on other request, when authenticate() is executed.
authenticate() could get the Authenticator from an AtomicReference in
the session (if available).
Given that the requested change will add complexity without actually
solving the problem any enhancement request opened asking for such a
change will be resolved as WONTFIX.
Oh come on.
Taking that sort of attitude is going to do nothing to help your case or
encourage anyone here to spend their time helping you.
You don't see the frustration you brought to me but you could read it. I
am sorry for that. In a world of asynchronous request handling and
protocol upgrading you are forcing users to deliver responses
sequentially. Sorry. This is so disappointing.
Not really. If you ensure that the authentication is done first, before
requesting any protected resources, you will then be able to deliver
things in parallel. It's just the initial request that is messing you
up, from what I understand of your description.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
