0003694: Search forces new user session

ID	Project	Category	View Status	Date Submitted	Last Update

0003694	OXID eShop (all versions)	4.02. Session handling	public	2012-03-08 23:27	2012-06-01 15:46

Reporter	Adrian.Kirchner	Assigned To
Priority	high	Severity	crash	Reproducibility	always
Status	resolved	Resolution	suspended
Product Version	4.5.4 revision 39463

Summary	0003694: Search forces new user session
Description	When the Fact Finder module is integrated the user session is forced at the first request. Since I don't have access to the unencrypted source of this module my guess is this circumstance takes place in the oxViewConfig::getFFChannel() method. This behaviour is especially bad if a reverse cache proxy is used. If this is done to track search requests with following orders pls start the tracking in the search view. Actually new user session is started on search in eShop. So the problem need to fix in eShop.
Steps To Reproduce	1) Delete all cookies or restart browser 2) Go to shop and make any search. 3) Find session cookie sid-it is already generated
Tags	No tags attached.

Theme	Both
Browser	All
PHP Version	any
Database Version	any

svetlana 2012-03-14 08:28 reporter ~0005979	@dev please check if it's really needed to start the session instantly when search is done. In this case user cannot use any caching tools for caching static content. Also one idea is that session in eShop is generated on POST method in forms. Maybe a fix here would solve the problem

mindaugas.rimgaila 2012-03-27 15:32 reporter ~0006098	POST request will not force to start the session any more.

dainius.bigelis 2012-05-08 09:46 reporter ~0006537	Reopened as fix was not correct and changes were rolled back.

dainius.bigelis 2012-06-01 15:45 reporter ~0006746	Reminder sent to: Adrian.Kirchner hi, Thanks for your feedback about the issue. We checked the case and looks like it's quite complicated. The regeneration of session ID is implemented on submiting the form because security purposes, mainly for user registration forms. That has side affect on search form also. When we tried to solve that by changing the GET method to POST - the case triggered more issues. so looks like we need to think about more conceptual solution for entire forms in eshop, maybe implementing something like PRG pattern, what could solve the case. But then it's more complicated change and can be done only in one of further eshop versions. So we included this task in our backlog to solve this, and here the entry is closed. Thank you for your feedback.