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