Tomcat 8.0.30 silently transforms 302 into 404
Hi, it seems that Tomcat 8.0.30 silently transforms a redirect response into a not-found response. https://bz.apache.org/bugzilla/show_bug.cgi?id=56917 introduces redirect to relative URLs. Before 8.0.30 a redirect URL string was simply returned to the client. Now it has to be a valid URI (not URL) for the response to succeed. If URI.create() fails, no error message is given or exception is thrown. Tomcat just sets the response code to 404. This behavior was introduced in revision 1717256. I appreciate stricter rules in this point, but please consider throwing a RuntimeException (best option) or at least log the error somewhere. kind regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ids of all active sessions
Am 18.01.16 um 09:35 schrieb Kaouthar Ghorbel: Hello everyone I want to retrieve the ids of all active sessions in the servlet. thanks for your help :) Hi Kaouthar, look for the HttpSessionListener and collect that information on your own: https://tomcat.apache.org/tomcat-8.0-doc/servletapi/javax/servlet/http/HttpSessionListener.html regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.30 Session lost
Am 13.01.16 um 15:48 schrieb Christopher Schultz: Thomas, On 1/13/16 8:31 AM, 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: Found on http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection the description how to switch the "feature" off. I will file two bugs soon describing the issues I had. Hopefully they will be fixed. 1.) if using HttpServetRequest.login(String, String) further request in the session are loosing the users Principal. 2.) After changing sessionId, old sessionIds should still be valid for a short period of time of to the same client. The second request will get closed as INVALID on security grounds. If the old ID is valid for any period of time it makes a session fixation attack possible. You might as well disable changing the session ID on authentication. 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. 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). Hi, "all but DIGEST are by default" was my case. As I walked through the code I found most of the features I requested are already in place. There is already the tracking of the Principal in the session. To use the values of login() later in authenticate() in Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my login-error-page. I think any value will do here ;-) FORM Restricted /foo /bar This activates the FormAuthenticator which correctly does, what I was hoping for. I think every authenticator can/should use the information stored by login() if it is available. Which argument to login() carries the server-generated nonce used for login? Which argument includes the realm name? https://en.wikipedia.org/wiki/Digest_access_authentication Hi Chris, the login() method gets the username and the password. It has nothing to do with configured auth-method in the web.xml. Tomcat uses a generic method[1] located in a super class do perform the login. The Principal is stored in the session, if caching is enabled and a session is present or created. Depending on the configured auth-method the Principal is used later, if found or not. My suggestion was to always use it, when it is stored in the session. Hope this clarifies my summary. Thomas [1] org.apache.catalina.authenticator.AuthenticatorBase.doLogin(Request, String, String) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.30 Session lost
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: Found on http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection the description how to switch the "feature" off. I will file two bugs soon describing the issues I had. Hopefully they will be fixed. 1.) if using HttpServetRequest.login(String, String) further request in the session are loosing the users Principal. 2.) After changing sessionId, old sessionIds should still be valid for a short period of time of to the same client. The second request will get closed as INVALID on security grounds. If the old ID is valid for any period of time it makes a session fixation attack possible. You might as well disable changing the session ID on authentication. 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. 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). Hi, "all but DIGEST are by default" was my case. As I walked through the code I found most of the features I requested are already in place. There is already the tracking of the Principal in the session. To use the values of login() later in authenticate() in Tomcat 8.0.30 I had to insert "/foo" as my login page and "/bar" as my login-error-page. I think any value will do here ;-) FORM Restricted /foo /bar This activates the FormAuthenticator which correctly does, what I was hoping for. I think every authenticator can/should use the information stored by login() if it is available. kind regards Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.30 Session lost
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 b
Re: Tomcat 8.0.30 Session lost
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: Found on http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection the description how to switch the "feature" off. I will file two bugs soon describing the issues I had. Hopefully they will be fixed. 1.) if using HttpServetRequest.login(String, String) further request in the session are loosing the users Principal. 2.) After changing sessionId, old sessionIds should still be valid for a short period of time of to the same client. The second request will get closed as INVALID on security grounds. If the old ID is valid for any period of time it makes a session fixation attack possible. You might as well disable changing the session ID on authentication. 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. 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(). 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. It's the same case with the logout() method. No problem there. Tomcat could handle this gracefully without any problems. 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. I showed, that there is a racing condition and *Tomcat* currently fails to do so. 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 file the bug, that's all a user can do. Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.30 Session lost
Am 11.01.16 um 22:05 schrieb Mark Thomas: Found on http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection the description how to switch the "feature" off. I will file two bugs soon describing the issues I had. Hopefully they will be fixed. 1.) if using HttpServetRequest.login(String, String) further request in the session are loosing the users Principal. 2.) After changing sessionId, old sessionIds should still be valid for a short period of time of to the same client. The second request will get closed as INVALID on security grounds. If the old ID is valid for any period of time it makes a session fixation attack possible. You might as well disable changing the session ID on authentication. 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 If login() modifies the session and the session does not track the authentication information, session tracking is not deterministic due to side effects for multiple requests at a time. Fixing either #1, #2 or #3 does not harm security at all but will fix this bug in Tomcat. I also tried to use authenticate() on the request, but instead of using the last login() credentials it forced the use of Basic Authentication. So really I do not see a option left on the developer side, how to use login() in a reliable manner. kind regards Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.30 Session lost
Am 11.01.16 um 12:21 schrieb André Warnier (tomcat): So the solution in your case, is to make sure, in your application logic, that the first unauthenticated request would be totally processed by the server, and the response processed by the client, before the client sends a second request. If you do this, then the second client request /will/ contain the /same/ authentication token as the first request, and you will not have this problem. How to achieve this, is left as an exercise for the reader. This means changing all browsers to submit only one concurrent request if the server is Apache Tomcat? Really? Found on http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection the description how to switch the "feature" off. I will file two bugs soon describing the issues I had. Hopefully they will be fixed. 1.) if using HttpServetRequest.login(String, String) further request in the session are loosing the users Principal. 2.) After changing sessionId, old sessionIds should still be valid for a short period of time of to the same client. Fixing one of these would cause the bug to disappear. To prevent session fixation attacks, I use IP address checking so that sessions are bound to the same IP address. Thanks to all the responses. Without you help it would have not been possible to get this fixed after two month of searching! kind regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.30 Session lost
Am 08.01.16 um 17:02 schrieb Christopher Schultz: Tomcat will change the session identifier when the user authenticates. If you are creating a session before login, you'll see that the session id changes when authentication is successful. This is to protect against session-fixation attacks. I re-login the user, if tomcat returns "null" on HttpRequest.getUserPrincipal(). I noticed that the sessionId changes. But if I am required to re-login the user on parallel requests, it depends on magic what sessionId is given after all responses are delivered to the browser. You can see in the logs, that requested sessions are suddenly invalid. I would not require an other call to the login method if servlet container returns a user once it is authenticated in a session. Can you explain why the changing session id breaks your application? Are you storing session ids somewhere and just not updating the session id list when the session id changes? It should be possibly to listen for that event and update your session id list. Or maybe there's a better way to accomplish your goal rather than keeping your own session id list. (I'm guessing you have a session id list because it would best explain the behavior you are describing here.) I do not save the http session id anywhere. The browser saves it in a cookie. The cookie is changing rapidly because the UserPrincipaö is not returned from the request. Here is something I would prefer: 1. Every request that belongs to a given session returns a non null object when calling getUserPrincipal() after the login() method returns successfully. 2. As you have no control over the net and do not know in which order the browser receives its packets, you can not invalidate a sessionId in a snap. Tomcat has to gracefully invalidate it somehow. An example: 1. Client logs in 2. Server responds with SID=SID1 3. Client request 2 resources in parallel 4. Server receives first request and handles it, returning SID=SID2 5. Server receives second request (with SID=SID2), which belongs to invalid session. Code is creating a new session than. Server response with SID=SID3 6. Client will use SID3 in future requests which belongs to the new session and not the original session where the user is logged in. IMHO it would be also secure to lock the sessionId to the IP address instead of changing the id but less error-prone. You can even combine it and allow old sessionIds only from the original IP address. If the servlet container would just use the session information for HTML pages parallel request are rare. But when serving cachable thumbnails it often like checking headers and return 304. kind regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.30 Session lost
Am 08.01.16 um 14:03 schrieb André Warnier (tomcat):
Hi Thomas.
It is a bit difficult to figure out where the problem really is, without
having the full picture of what is going on (your web.xml configuration,
the order and precise timing in which requests really happen etc.).
But one thing I would really focus on, is the general overall logic of
the application, to see if the order in which things happen is really
consistent with the authentication method that you are using.
For example, if the initial call to the first page (the one which
contains the document links) does not immediately trigger a session
authentication, and in the meantime the browser starts making multiple
quasi-simultaneous requests for the links present in that page, then
things would get out of sync, since when the authentication does happen,
the session-id /will/ change (check Wikipedia for "web session
fixation"). That would overwrite the session-id cookie, perhaps in the
middle of the calls still being made to retrieve the document links
mentioned in the page.
Hi André,
I would like to give some insight information on how authentication is
handled.
As the application can run in command line or as a web application we
have a custom session handling (refer to it as 'core session'). Within
the core session there is a UserInformation implementation attached.
UserInformation can have different implementations and allows to ask for
the user id and if the user in in a specific role.
In the HttpSession we only store the sessionId of our core session. When
the http session is destroyed we also close the core session.
So there is only this one property "mycore.session" in the httpsession.
When using servlet container authentication (error happens only with
it). I need to access the request object which is stored in a
ThreadLocal and released at end of the request.
Here are the most important methods
private void loginIfNeeded() {
//getCurrentRequest() returns Optional
getCurrentRequest().ifPresent(currentRequest -> {
if (currentRequest.getUserPrincipal() == null) {
try {
currentRequest.login(user, pwd);
LOGGER.debug("Re-Logged in: " + user);
} catch (ServletException e) {
throw new RuntimeException(e);
}
}
});
}
public String getUserID() {
loginIfNeeded();
lastUser = getCurrentRequest()
.flatMap(r -> Optional.ofNullable(r.getUserPrincipal()))
.map(Principal::getName)
.orElseGet(() -> Optional.ofNullable(lastUser)
.orElseGet("guest");
return lastUser;
}
public boolean isUserInRole(String role) {
loginIfNeeded();
return getCurrentRequest().map(r ->
r.isUserInRole(role)).orElse(Boolean.FALSE);
}
When the user first authenticated with his login credentials we put the
servlet container user information to the core session. As the HTTP
session is linked to it, we just need the http session to keep track of it.
The error happens to be later, (possibly) many requests after the login
form that put UserInformation to the core session. So there is no racing
condition at that position.
You can see in the code that I need to re-login from time to time, as
the request object does not always return the remote user.
Why does that change the sessionId? How can I track the user than?
IMHO if HttpServletRequest.login() should only be called once in a http
session than getUserPrincipal() should always return a user after
login() is called on one request regarding to the same session, or?
But if calling login() always invalidates the old session we have a
problem here.
As long as request are coming in sequentially this would be OK, as the
browser gets a new cookie value with every response. But browsers are
out of control and want to give cpu cores a good time.
Anyway. I hope you are not lost in the details and are still willing to
help me.
regards,
Thomas
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.30 Session lost
Am 08.01.16 um 11:43 schrieb Olaf Kock: Is there any chance that the first and correctly authenticated cookies (despite the debug output "secure=false") are https-only cookies and won't get transmitted in http, thus triggering new sessions? E.g. any chance they get rewritten at another level (Apache httpd, ServletFilter, others) to be secure only - or that the debug output is slightly incorrect because it omits the secure flag? This is from a test installation on the productive server where it can only be observed. For simplicity I use the maven cargo plugin to setup the tomcat here. It shows the same behavior on the productive server, where it uses HTTPS in combination with Apache HTTPD. I use BeanUtil.describe() to produce the cookie String. So this should all be correct. This error comes up on every browser with at least a certain number of request to that servlet. It has something to do with a race condition or side effect I'm not aware off. If I do not use container authentication, HTTP sessions won't get lost. Hunting this bugs for so many weeks now and ran out of ideas. regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.0.30 Session lost
Hi,
I have a very rare problem regarding session handling. It is
reproducible only on a single server environment. Of cause this is the
productive server.
I use container authentication and for simplicity 'tomcat-user.xml'.
Login is done via HttpServletRequest.login() method, whenever I need to
access user and role information. The HttpServletRequest is saved in a
ThreadLocal during request processing.
While that normally does the job. There is one servlet that produces
simple thumbnails that triggers a problem. Session handling is done via
Cookies.
A search result page lists several thumbnail images and the browser
tries to load them (of cause) in parallel.
After the first thumbnail is loaded, the sessionId suddenly changes. As
the browser now submitting the "false" sessionId, new sessions are
created and the browser gets that new sessionId in the response. The
session from the first request is lost at that point and so are the
login credentials.
Why are sessionIds changing during the request?
Here are the logs I produce via a Servlet Filter:
- REQUEST -
[dev-mir] DEBUG MCRRequestDebugFilter: REQUEST URI:
/mir/img/pdfthumb/Document_derivate_0049/2015-05-06_Protokoll%20der%20Sitzung%20des%20Fakult%C3%A4tsrates_%C3%B6ffentlich.pdf
Cookies:
{path=null, maxAge=-1, domain=null, name=JSESSIONID, comment=null,
httpOnly=false, secure=false, class=class javax.servlet.http.Cookie,
value=BD12BA0ED4546B5BC119727DAF97086B, version=0}
COOKIES END
REQUEST PARAMETERS:
centerThumb: no,
REQUEST PARAMETERS END
Session is requested by cookie.
Session is not requested by URL.
Session is valid.
SESSION BD12BA0ED4546B5BC119727DAF97086B created at: 2016-01-07T15:18:51.068
SESSION ATTRIBUTES:
mycore.session: {}
SESSION ATTRIBUTES END
Header:
accept: image/png,image/*;q=0.8,*/*;q=0.5
accept-encoding: gzip, deflate
accept-language: en-US,en;q=0.5
cache-control: max-age=0
connection: keep-alive
cookie: JSESSIONID=BD12BA0ED4546B5BC119727DAF97086B
host: cms.example.com:8291
if-modified-since: Wed, 06 Jan 2016 14:40:00 GMT
if-none-match: "4e0daa3453247bcfd985ee28de9616de"
referer:
http://cms.example.com:8291/mir/servlets/solr/select?q=objectType:mods%20AND%20createdby:protokoll&sort=mods.dateIssued%20desc
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Firefox/38.0
HEADERS END
- RESPONSE -
[dev-mir] DEBUG MCRRequestDebugFilter: RESPONSE URI:
/mir/img/pdfthumb/Document_derivate_0049/2015-05-06_Protokoll%20der%20Sitzung%20des%20Fakult%C3%A4tsrates_%C3%B6ffentlich.pdf
Status: 304
Header:
Cache-Control: max-age=31536000
ETag: "4e0daa3453247bcfd985ee28de9616de"
Expires: Sun, 24 Jan 2016 15:30:02 GMT
Set-Cookie: JSESSIONID=0A88AABC33D336900279B2378CD510B1; Path=/mir/;
HttpOnly
HEADERS END
- NEXT REQUEST -
[dev-mir] DEBUG MCRRequestDebugFilter: REQUEST URI:
/mir/img/pdfthumb/Document_derivate_0047/2015-03-25_Protokoll%20der%20Sitzung%20des%20Fakult%C3%A4tsrates_%C3%B6ffentlich.pdf
Cookies:
{path=null, maxAge=-1, domain=null, name=JSESSIONID, comment=null,
httpOnly=false, secure=false, class=class javax.servlet.http.Cookie,
value=BD12BA0ED4546B5BC119727DAF97086B, version=0}
COOKIES END
REQUEST PARAMETERS:
centerThumb: no,
REQUEST PARAMETERS END
Session is requested by cookie.
Session is not requested by URL.
Session is not valid.
Header:
accept: image/png,image/*;q=0.8,*/*;q=0.5
accept-encoding: gzip, deflate
accept-language: en-US,en;q=0.5
cache-control: max-age=0
connection: keep-alive
cookie: JSESSIONID=BD12BA0ED4546B5BC119727DAF97086B
host: cms.example.com:8291
if-modified-since: Wed, 06 Jan 2016 14:40:02 GMT
if-none-match: "9e485dcd85a2b2ee373717a67c282873"
referer:
http://cms.example.com:8291/mir/servlets/solr/select?q=objectType:mods%20AND%20createdby:protokoll&sort=mods.dateIssued%20desc
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
Firefox/38.0
HEADERS END
[dev-mir] DEBUG MCRServlet: Setting ReqCharEncoding to: UTF-8
[dev-mir] DEBUG MCRHttpSessionListener: HttpSession
20934FB3493889B9EE0FB425A002BB28 is beeing created by:
org.apache.catalina.session.StandardSessionFacade@6a75756b
- RESPONSE -
[dev-mir] DEBUG MCRRequestDebugFilter: RESPONSE URI:
/mir/img/pdfthumb/Document_derivate_0047/2015-03-25_Protokoll%20der%20Sitzung%20des%20Fakult%C3%A4tsrates_%C3%B6ffentlich.pdf
Status: 304
Header:
Cache-Control: max-age=31536000
ETag: "9e485dcd85a2b2ee373717a67c282873"
Expires: Sun, 24 Jan 2016 15:30:03 GMT
Set-Cookie: JSESSIONID=20934FB3493889B9EE0FB425A002BB28; Path=/mir/;
HttpOnly
HEADERS END
kind regards,
Thomas
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.0.5 and web resource cache
Hi, I recently noticed that Tomcat 8.0.5 does not invalidate cache entries for web resources. Here are the steps to reproduce: 1. make "/foo.html" available through a jar file -> META-INF/resources/foo.html 2. Open foo.html in your browser 3. Add a new file "foo.html" inside you webapp directory with different content. 4. Refresh foo.html in your browser. One would expect to see the content of the file that was added in step 3. But Tomcat caches the URL it resolved in step 2 and sticks to it forever. This is new in Tomcat 8. I would prefer that Tomcat always check the current webapp directory and uses it cache only for the *.jar files. kind regards, Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 ClassLoader
Am 10.02.2014 14:43, schrieb Mark Thomas: On 10/02/2014 12:59, Thomas Scheffler wrote: Am 10.02.2014 12:58, schrieb Mark Thomas: On 10/02/2014 10:58, Thomas Scheffler wrote: Hi, I noticed an incompatibility after testing my web application with Tomcat 8 RC5 and Tomcat 8.0.1 I allow users of my web application to configure the web application with external configuration. This is also where the user is allowed to specify additional libraries to load into the web application (e.g. database driver). When you start using reflection to access class loader internals (or any other internals) that is usually a sign that the solution is going to be fragile. In this case, the resources refactoring in Tomcat 8 removed a whole bunch of code from WebappClassLoader, including the addURL implementation. The 'correct' way to do this in Tomcat add is to add an appropriate nested element to the context. It may be possible to restore the functionality you were depending on. Are you able to build Tomcat 8 from trunk and test it if I make some changes? The ideal solution would be for this to be handled as part of the Servlet spec. Hopefully, the concept of overlays (which should handle this) will return in 3.2 after being pulled from 3.1. Hi, thank you for your offer. I will test your fixes, if you provide that in trunk. Just give me a notice. Apache Solr is doing similar stuff. I had not tested if their library code still works and - if so - how it differs. Using won't help as the configuration directory is determined on run-time (using heuristics, context information and system properties voodoo). OK, try the current code in trunk. addURL() should be working again. Yes, indeed. Thanks for your quick help. kind regards Thomas - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 ClassLoader
Am 10.02.2014 12:58, schrieb Mark Thomas: On 10/02/2014 10:58, Thomas Scheffler wrote: Hi, I noticed an incompatibility after testing my web application with Tomcat 8 RC5 and Tomcat 8.0.1 I allow users of my web application to configure the web application with external configuration. This is also where the user is allowed to specify additional libraries to load into the web application (e.g. database driver). When you start using reflection to access class loader internals (or any other internals) that is usually a sign that the solution is going to be fragile. In this case, the resources refactoring in Tomcat 8 removed a whole bunch of code from WebappClassLoader, including the addURL implementation. The 'correct' way to do this in Tomcat add is to add an appropriate nested element to the context. It may be possible to restore the functionality you were depending on. Are you able to build Tomcat 8 from trunk and test it if I make some changes? The ideal solution would be for this to be handled as part of the Servlet spec. Hopefully, the concept of overlays (which should handle this) will return in 3.2 after being pulled from 3.1. Hi, thank you for your offer. I will test your fixes, if you provide that in trunk. Just give me a notice. Apache Solr is doing similar stuff. I had not tested if their library code still works and - if so - how it differs. Using won't help as the configuration directory is determined on run-time (using heuristics, context information and system properties voodoo). regards, Thomas Scheffler - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8 ClassLoader
Hi,
I noticed an incompatibility after testing my web application with
Tomcat 8 RC5 and Tomcat 8.0.1
I allow users of my web application to configure the web application
with external configuration. This is also where the user is allowed to
specify additional libraries to load into the web application (e.g.
database driver).
This code worked in Tomcat 7 and Jetty 8 - 9.1 but does not work anymore
in the current version of Tomcat:
if (libDir != null && libDir.isDirectory()) {
File[] listFiles = libDir.listFiles(new FilenameFilter() {
public boolean accept(File dir, String name) {
return name.toLowerCase().endsWith(".jar");
}
});
if (listFiles.length > 0) {
ClassLoader classLoader = this.getClass().getClassLoader();
Class classLoaderClass =
classLoader.getClass();
try {
Method addUrlMethod =
URLClassLoader.class.getDeclaredMethod("addURL", URL.class);
addUrlMethod.setAccessible(true);
for (File jarFile : listFiles) {
try {
addUrlMethod.invoke(classLoader, jarFile.toURI().toURL());
} catch (IllegalAccessException | IllegalArgumentException |
InvocationTargetException | MalformedURLException e) {
e.printStackTrace();
}
}
} catch (NoSuchMethodException | SecurityException e) {
e.printStackTrace();
}
}
Using Tomcat 8 there is no error message when I use the "addURL" method.
But any class inside the jar files is not found afterwards.
Any help to work-around the problem is highly appreciated :-)
kind regards,
Thomas
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
