View Issue Details
|OXID eShop (all versions)
|4.02. Session handling
|Fixed in Version
|0007223: force session start leads to sid parameters on all links on first page request
|When the config param blForceSessionStart is set to true, all article links are rendered with an unnessecary force_sid get param on the first page request.
The method isSidNeeded() in the class \OxidEsales\Eshop\Core\Session accepts an optional parameter $sUrl. If this is set, the method checks if the url matches the current base url and returns true, if both don't mach. This makes sense to keep sessions accross different domains.
But in addition, the method also should return false if both do match - as the force_sid param is superfluos when rendering article links on the same domain. Instead the method does a check for _forceSessionStart() furter down an returns true also for link rendering.
I think the additional condition above should be added to the method
|Steps To Reproduce
|1. Set blForceSessionStart to true in config.inc.php
2. Clear server sessions and cookies in browser or use a fresh/private instance
3. Request a page with article links, for example the start page
4. Check the rendered article links. A force_sid param is present on all links.
|The problem here is that a lot of our new users add bookmarks to articles or even share those links with the superfluos force_sid param. When they or another user call these links later on they run into problems with mismatching CSRF Tokens when they try to add articles to their baskets.
|No tags attached.
I should mention that this is not as simple as it might seem, since the sid param mandatory for example when logging into the admin backend. Thus a check must take into account what link type is rendered and where.
Hope this helps.
The option forces a session start on the first page load and is intended for users whose browsers do not accept cookies. That is why the sid parameter is appended to URLs:
So your description is the expected behavior. For this reason, I am closing the bug. You are welcome to reopen the ticket if you have more information.
|This behavior also affects users whose browsers do accept cookies (like 99% of all users). In this case it doesn't make sense as described above, whereas a forced session start sometimes is needed not just for the minority of users whose browsers don't accept cookies.
The option dates back to a time when cookies were not used. This explains why the force_sid parameter is used in the URL by default. There is no other behavior and no check whether cookies are possible or not.
The option still exists for compatibility reasons and was not intended to cover the behavior you want.
Nevertheless, I will discuss the option internally.