Tomcat 8.0.30 silently transforms 302 into 404

2016-01-28 Thread Thomas Scheffler

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

2016-01-18 Thread Thomas Scheffler

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

2016-01-13 Thread Thomas Scheffler

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

2016-01-13 Thread Thomas Scheffler

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

2016-01-12 Thread Thomas Scheffler

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

2016-01-12 Thread Thomas Scheffler

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

2016-01-12 Thread Thomas Scheffler

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 

Re: Tomcat 8.0.30 Session lost

2016-01-11 Thread Thomas Scheffler

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

2016-01-11 Thread Thomas Scheffler

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



Tomcat 8.0.30 Session lost

2016-01-08 Thread Thomas Scheffler

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=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=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



Re: Tomcat 8.0.30 Session lost

2016-01-08 Thread Thomas Scheffler

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



Re: Tomcat 8.0.30 Session lost

2016-01-08 Thread Thomas Scheffler

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



Tomcat 8.0.5 and web resource cache

2014-04-10 Thread Thomas Scheffler

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



Tomcat 8 ClassLoader

2014-02-10 Thread Thomas Scheffler

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? extends ClassLoader 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



Re: Tomcat 8 ClassLoader

2014-02-10 Thread Thomas Scheffler

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 Resources ... / 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 Resources 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



Re: Tomcat 8 ClassLoader

2014-02-10 Thread Thomas Scheffler

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 Resources ... / 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 Resources 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