[Done 160] V154 & V155 cookies off zenid changing w every page change. add item fails

Looks like I am not unique. just seen this post on responsive sheffield blue.
https://www.zen-cart.com/showthread.php?217203-Responsive-Sheffield-Blue-v2-0&p=1315906#post1315906
Solution enable cookies. But how do we tell our users to do that?

DrByte:

init_sessions.php
Argh; I'm not seeing that. Very curious why it seems to be unique to your setup...

brittainmark:

Looks like I am not unique. just seen this post on responsive sheffield blue.
Solution enable cookies. But how do we tell our users to do that?
I can't speak to whatever that 3rd party plugin is doing to force the need for cookies, particularly in a mode that is specific to that template.

Agreed. It is just that they are having the same issue I am going to timeout when cookies are turned off. Even when I use the vanilla install of zen cart.

DrByte:

I can't speak to whatever that 3rd party plugin is doing to force the need for cookies, particularly in a mode that is specific to that template.

Hi Mark.

Have been doing some digging and testing regarding this after some discussions with DrByte.

Firstly regarding your suggestion

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()]);
}  

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)

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.

Hi so have done an initial PR for v1.6

https://github.com/zcwilt/zc-v1-series/commit/285288132585e6034754f86c51a076103a726f40

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:

    $_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;

AFTER:

    $_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;

The cookies warning now appears when you add to cart and on attempting to logon have not pested beyond that.

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

wilt:

Hi so have done an initial PR for v1.6

https://github.com/zcwilt/zc-v1-series/commit/285288132585e6034754f86c51a076103a726f40

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.