0003573: Basket Problem: If User use the "Back" Button of browser, then the page will not appear - OXID eShop bugtrack

ID	Project	Category	View Status	Date Submitted	Last Update

0003573	OXID eShop (all versions)	4.08. Cache	public	2012-02-10 11:31	2012-12-10 13:39

Reporter	Benutzer	Assigned To
Priority	normal	Severity	major	Reproducibility	always
Status	resolved	Resolution	suspended
Product Version	4.5.7 revision 41909

Summary	0003573: Basket Problem: If User use the "Back" Button of browser, then the page will not appear
Description	I'll checked this with Firefox 10, EE 9 and Chrome 16.0.912.77 m and in OXID CE, PE and EE from 4.2 to 4.5.7. For errors see the screenshots.
Steps To Reproduce	To reproduce this in http://demoshop.oxid-esales.com/professional-edition/ do following steps: 1. put something to the cart 2. go to the cart 3. go on step 1 (defaul you'll see step 2) 4. do next step 5. take first option 6. and now use the browsers back button For basic theme the steps 3 and 4 are not necessary, but the result is the same ;(
Tags	No tags attached.
Attached Files	10-02-2012 11-17-11.png (35,631 bytes) 10-02-2012 11-17-11.png (35,631 bytes) 10-02-2012 11-18-52.png (34,389 bytes) 10-02-2012 11-18-52.png (34,389 bytes) 10-02-2012 11-19-51.png (32,468 bytes) 10-02-2012 11-19-51.png (32,468 bytes) 10-02-2012 11-20-49.png (33,105 bytes) 10-02-2012 11-20-49.png (33,105 bytes) 10-02-2012 11-21-44.png (28,404 bytes) 10-02-2012 11-21-44.png (28,404 bytes) oxcmp_redirect.zip (1,058 bytes)

Theme	Both
Browser	All
PHP Version	any
Database Version	any

tomas_liubinas 2012-02-15 15:31 reporter ~0005746	That happens because browser asks the permission to resubmit the form (the one you submitted by pressing "Weiter" button in step 1.). From browsers perspective that is correct "Back" button functionality. I would say this is correct, any web form on internet would work like that. So I would say this is not a bug.

leofonic 2012-02-20 04:59 reporter ~0005778	I agree this is not a bug, but it could be avoided for better usability with this mechanism: http://en.wikipedia.org/wiki/Post/Redirect/Get

arvydas_vapsva 2012-02-20 14:54 reporter ~0005781	sure, this idea is well known and we will implement it one day, just we cant implement it right now due to.. Imagine use case - standard shop form containing few INPUT fields and few hidden parameters. When form is submitted shop interprets these parameters and performs actions. Yes - here we could collect them and transfer/redirect (if needed) to (same, dedicated, another) view after form is posted by attaching them to header location. But what if you need additional form parameters? Yes, user could add them to form and we can dinamically transfer them to next page. But here comes possible security issues, xss or so. So - we need to add some additional input sanitizing functionality to filter/check input (which may later be used on page or so). We dont have it and this feature can not be implemented in next patch just like that. This feature can be implemented ONLY in next major version with additional warning about upcoming change. What YOU can do (quick and dirty fix) for your projects if this drawback really annoys and you are ready to take responsibility - change form(s) type(s) from POST to GET (like it is now in search), but this means that your shop will expose some user input.. Also - can you enter this feature request to OXID user voice (http://oxid.uservoice.com/forums/31940-feature-requests)?

saschagruen 2012-03-27 08:53 viewer ~0006094	FYI: The same problem also appears if you goto list page, select some filters, click on an article and then use the "back"-button.

dainius.bigelis 2012-04-20 10:01 reporter ~0006366	After some discussions in team, we decided to do more complex solution to solve this problem in general in entire eShop. Need to prepare the concept for that, which would cover all the cases and handle transactions properly. So the fix for that will be prepared in some later versions.

leofonic 2012-05-10 13:10 reporter ~0006557	Just a few thoughts: If action is performed right after post, and then the redirect leads to a generic page (like "/basket"), no additional input sanitizing is neccessary. I wrote a small component based on the existing redirect in oxcmpbasket for testing purposes which i attached (This is not meant as a solution, just to test the idea). This fails if a) output is based on actions in view, like "Entry saved", or b) if form params are inserted in output, like in the form to subscribe the newsletter. There could be a special place in the session to store those and output on redirected page (like in oxutilsview::addErrorToDisplay) or those could maybe be passed as GET params to the next page.

dainius.bigelis 2012-06-05 17:22 reporter ~0006785	As I wrote to the related bug comments: We checked the case and looks like it's quite complicated. The regeneration of session ID is implemented for security purposes. So when you click Back on browser, after the form is submited, it tries to get user back to previous page WITH previous session. That's leads to such cases as described. One of possible solutions would be implementing the PRG pattern in eShop entirely, for all the forms. but that is also related with data handling during the order in various circumstances. So we tend to go for more general solution for entire shop. We included this task to our backlog, to solve that kind of issues in one of further version releases. Entry here is closed.