So you have some kind of custom extension thats using hard coded session ids?? I'm pretty sure the problem then is not Joomla's fault, but the hard coded use of session ids.

//paging @mbabker

Yes, it is a custom extension. But we only use the joomla session id.
$session = \JFactory::getSession();
$sessionid=$session->getId();

The advantage was that we only use the joomla session and no custom cookie. With the user logout, the link between the user (his browser) and shoppingcart is cut. So we don't need a logout plugin to delete a custom cookie with userlogout. That was secure because we only use the joomla core and not any custom code.

Now i changed my code and use a custom cookie. But this will not delete automatically with the user logout. So i must write a additional plugin to do that. But i think more extensions means less security.

Therefore I dont see this as being a core Joomla issue, but one that you need to change in your custom code.

Regeneration of the session on login helps to defend against session fixation and login CSRF issues and is best practice.

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Renew_the_Session_ID_After_Any_Privilege_Level_Change

This could be considered a b/c break however...

//paging @mbabker ;-)

I guess you could argue either way about it. To me the new behavior is correct in part for the reasons pointed out on the OWASP docs. If it's really that major of a hinderance I guess reverting can be considered (it wasn't a patch due to an active security issue, rather a hardening based on a known weakness), but I'd rather wait and see how major of an issue it might be before suggesting it. Secure sessions aren't easy.

More security, yes. But all extensions lost user tracking after login. So developer must use there own solutions e.g. in Shops. With there solution you get less security in joomla. Final it doesnt matter how a joomla site is hacked.

sessions are only one way to track a user - big shops on multiple server set ups (like amazon.com) certainly dont use sessions ;-)

@PhilETaylor

Please clarify a question (i have not checked yet, i will)

• the session id changes, and all data stored data into session before use-login are lost ?
• or only session id change , and data stored in Joomla session are not lost ?

Im on the road at the moment - @mbabker might be able to quickly answer that

The session is "forked". JSession::fork() is called which migrates the existing session data to what is in essence a new session with a new ID.

I don't store data in the joomla session. I only use the session id in my own table.

My understanding was that a session was for maintaining information etc across a users visit. By the fact that they changed from anonymous to registered I would have thought that classed as two separate users. The anonymous users session ended when they logged in and create a new session as a registered user.

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Renew_the_Session_ID_After_Any_Privilege_Level_Change

The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state

I say this issue can be closed (@brianteeman) because this is not a core bug, the issue probably is that Joomla could have communicated with its community developers about the change better, but the actual change is solid in its foundation and purpose.

@thomaslanger Why don't you just store your own key to the session and use that to fetch the information from your table? It would be more efficient to use integers instead of session id..

Like @mbabker said, all the information from the session is maintained after login (except for session id).

I am going to close this. Unfortunately yu have been effected by this change but it has been done for good reasons