Hi all,

first of all sorry if some of you already answered on my IRC request on freenode but due to network policy in my company I could only connect via web and have been disconnected without access to channel history.

I apologize if you already took time to answer on the channel but I could not see your answer.

The problem I have is around the 'ChangeSessionIdOnLogin' feature implemented in undertow. I understand that the feature is there in order to avoid attacks via session reuse (exposing a link with an already provided JSESSIONID for example).

In one of our application, a SPA application with some server side HttpSession caching, during initialization a bunch of asynchronous calls are performed. Due to the 'ChangeSessionIdOnLogin' feature several of them are failing.

I have implemented a simple reproducer application exposing the problem and possible workarounds (examples are self runnable using maven : https://github.com/McFoggy/jsessionid-concurrency).

In the provided reproducer app we workaround the JSESSIONID regeneration by either:

  - making a fake call before the asynchronous calls are performed (changing the JSESSIONID before parallel calls occure)

  - disabling the 'ChangeSessionIdOnLogin' feature using an undertow ServletExtension

The real question I have is why the created session is not trusted (see https://github.com/undertow-io/undertow/blob/master/servlet/src/main/java/io/undertow/servlet/handlers/security/CachedAuthenticatedSessionHandler.java#L93) when the HttpSession is created by an authenticated call without incoming JSESSIONID?

Is this a bug? I'll fill an issue if so.

Is this a feature? In this case what is the recommendation to avoid this when several calls are issued before JSESSIONID stabilization like in the demo project? 

Thanks for any hint & answer.

Matthieu

- - - - - - - - - - - - - - - -

http://blog.matthieu.brouillard.fr/

http://oss.brouillard.fr/

https://github.com/McFoggy

https://twitter.com/alightinthefog