Looks like I am not unique. just seen this post on responsive sheffield blue.
https://www.zen-cart.com/showthread....06#post1315906
Solution enable cookies. But how do we tell our users to do that?
Looks like I am not unique. just seen this post on responsive sheffield blue.
https://www.zen-cart.com/showthread....06#post1315906
Solution enable cookies. But how do we tell our users to do that?
Mark Brittain
http:\\innerlightcrystals.co.uk\sales\
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
Mark Brittain
http:\\innerlightcrystals.co.uk\sales\
Hi Mark.
Have been doing some digging and testing regarding this after some discussions with DrByte.
Firstly regarding your suggestion
The problem here is that propagating the $_GET opens up code to some session hijacking/fixation hacks. We allow it for SSL as there is other code to mitigate the hacks (e.g. SSL only cookies and session_regenerate on login)Code:if (isset($_POST[zen_session_name()])) { zen_session_id($_POST[zen_session_name()]); } elseif ( ($request_type == 'SSL') && isset($_GET[zen_session_name()]) ) { zen_session_id($_GET[zen_session_name()]); /* else if added Mjfb*/ } elseif (isset($_GET[zen_session_name()])) { zen_session_id($_GET[zen_session_name()]); }
Note.There are some other things that could be done to allow for this code change, but still mitigate against hacking.
The upshot is, that you are correct, that if a user has cookies disabled then they will get changing session id's and a useless catalog.
The workaround suggested is to turn on force cookie usage. This doesn't fix the changing id's but should warn the user if they have cookies turned off.
This warning is supposed to happen when they try to add something to the cart (and a few other places) but as you have pointed out when adding to cart, the user is redirected to the timeout page instead.
This is a bug, and seems to have been caused by the introduction of csfr token checking (again this is security code meant to mitigate against other hacks)
It was our intention at some point to make Force Cookie Usage a default at some point, and maybe we should have done this earlier in the v15 code. It would have probably raised the timeout issue much earlier.
I'm going to raise this issue as part of our v1.6.0 code, however the intention would be to backport changes into v1.5.x.
I will update this thread once I have committed code to Github
Ok. If I can do any testing to help just let me know.
Mark Brittain
http:\\innerlightcrystals.co.uk\sales\
Hi so have done an initial PR for v1.6
https://github.com/zcwilt/zc-v1-seri...a076103a726f40
This should fix the problem of seeing the session timeout page rather than the Cookie Usage page when adding to cart and first party cookies being disabled.
I have made the following mod to 155 and it now say about cookies about line 25 in includes>init_includes>init_sanitize.php (same in 154). and turned on force cookie usage in Admin>configuration>sessions.
BEFORE:
AFTER:PHP Code:
$_SESSION ['securityToken'] = md5 ( uniqid ( rand (), true ) );
}
if ((isset ( $_GET ['action'] ) || isset($_POST['action']) ) && $_SERVER['REQUEST_METHOD'] == 'POST')
{
$mainPage = isset($_GET['main_page']) ? $_GET['main_page'] : FILENAME_DEFAULT;
The cookies warning now appears when you add to cart and on attempting to logon have not pested beyond that.PHP Code:
$_SESSION ['securityToken'] = md5 ( uniqid ( rand (), true ) );
}
if ((isset ( $_GET ['action'] ) || isset($_POST['action']) ) && $_SERVER['REQUEST_METHOD'] == 'POST')
{
if (!$session_started) {
zen_redirect(zen_href_link(FILENAME_COOKIE_USAGE));
}
$mainPage = isset($_GET['main_page']) ? $_GET['main_page'] : FILENAME_DEFAULT;
Thanks for looking at this. Haveing does some research on session hijacking/fixation hacks I see the problem with my code. There appears to be a limit to what you can do to prevet this you just have to make it as hard as possible.
Thanks again
Mark
Mark Brittain
http:\\innerlightcrystals.co.uk\sales\
Bookmarks