[undertow-dev] ChangeSessionIdOnLogin unexpected behavior during SPA initialization

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...) 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