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.
It's the same case with the logout() method. No problem
there. Tomcat could handle this gracefully without any problems.
As I explained above, this can't be handled gracefully even with the
changes you are requesting to Tomcat. Tomcat is required by the Servlet
spec to throw a ServletException if a call to login() is made after a
user has already been authenticated. The Servlet API does not provide
the hooks necessary for an application to handle the race condition of
parallel requests that require authentication and prevent this exception.
Yes, the application could simply catch the exception and carry on but
such a design is a large warning that that API is not being used correctly.
The spec just states that the user information on the request does not
change if one does not call login(), logout() or authenticate(). It says
nothing on the initial state, neither. But when I call authenticate() on
a request and used login() on an other request object, why can't
authenticate() not use that credentials? Why does the user have to
re-login again (basic auth)?
Therefore, I come back to my earlier point that the correct solution is
for the application accesses authenticated resources in a sane way and
then these issues simply won't be possible. In the specific example for
this thread, the page that generates the list of thumbnails needs to
require authentication as well as (some of) the thumbnails.
It boils down to this problem:
It's the servlet containers duty to do the session tracking.
Not correct. Responsibility for correct session tracking is split
between the container, the browser and the application.
You are right. But I have no code to alter the session handling. It is a
standard webpage with restricted information that refers to restricted
images on the same fast server. A rather simple use case. I use the
login() method that was introduced in Servlet 3. There is no standard
conform way to have login() work for me. I cannot modify the browser to
load the images one by one. I could do by using JavaScript to load the
images and waiting for each response. Is that what you are suggesting?
You could also listen to the advice you are being given. You need to
change the way your application behaves to avoid it making requests in
parallel that may require authentication. That has always been
problematic and now applications and containers need to worry about
session fixation it is even more likely to be problematic.
If you look back in the archives several years ago when HTML frames were
popular similar issues existed. The solution then was to ensure that a)
the top-level frame required authentication and b) after any
authentication the user was always redirected to a new top-level frame.
This is broadly analogous to your page with multiple thumbnails. If you
make the page that references the thumbnails require authentication then
the problem will be solved.
It is just like a homepage that give a tiny information, who is logged
in. And depending on the user returns some information not readable by
"guests". No way to force a user to enter his credentials. You can visit
twitter without being asked for your login. You decide when you log in
and you never loose a session. One URL returns different results
depending on the user being logged in.
Of cause, if I require authentication, I can force Tomcat to not use
BasicAuthentication but FormAuthentication. But during the page
generation I used the login() method to get the user information and
check for roles. The page is delivered to the user referencing
thumbnails that are itself protected and lack of authenticate() to work
as expected, calling login() with the same credentials all over again
for every thumbnail. That's causing all the trouble.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
