On 12/01/2016 13:03, Thomas Scheffler wrote: > Am 12.01.16 um 13:24 schrieb Mark Thomas: >> On 12/01/2016 11:06, Thomas Scheffler wrote: >>> Am 11.01.16 um 22:05 schrieb Mark Thomas:
<snip/> >>>> For the first the description above isn't clear enough to be sure >>>> exactly what you are asking for. However, based on the second request >>>> and what I have read of this thread I suspect that request will get >>>> closed as INVALID or WONTFIX. >>> >>> Hi Mark, >>> >>> if you choose to use login() and this modifies the session ID. Further >>> calls to login() should either: >>> >>> 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. >> 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. >> This request is asking that any method call on the request relating to >> authentication checks the session if the authenticator is configured to >> cache authentication information in the session. >> >> While this is possible, it won't solve the problem. There will still be >> a race condition in the application. Consider the following: >> Request1 - getRemoteUser() == null; >> Request2 - getRemoteUser() == null; >> Request2 - login() - OK >> Request1 - login() - ServletException as user is already logged in >> >> 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. > 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. >> 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. > I showed, > that there is a racing condition and *Tomcat* currently fails to do so. You have demonstrated that you are observing a problem with your application and have correctly diagnosed why you are seeing the behaviour you are seeing. However, what you have not done is demonstrated that the root cause of the problem is in Tomcat. > The client (every browser on the market) are not the problem here, they > behave like they should (Tomcat tells to value of the session cookie!) I agree. There is no evidence of a user-agent issue in this thread. > I file the bug, that's all a user can do. 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
