Zenid text intermittently populates all website product category links

We have recently updated our website OS to openSuSE 13.1 but have since experienced problems with the site.
Regardless of whether we use Opera, Chrome, Firefox or Konqueror to view the site we find that it sometimes adds a string of zenid text to the product categories. For example......

http://www.fort777.co.za/index.php?main_page=index&cPath=1

is stored and loads as:-

http://www.fort777.co.za/index.php?main_page=index&cPath=1&zenid=bvuac71knms96vg2j0ss8ivdrce9u8iae4omjjck4c8b535ngsj0

Refreshing the home page often clears the additional text from all of the product categories urls and the site behaves as it should.

Does anyone have any suggestions as to how we can fix this problem?

BlightyExPat:

We have recently updated our website OS to openSuSE 13.1 but have since experienced problems with the site.
Regardless of whether we use Opera, Chrome, Firefox or Konqueror to view the site we find that it sometimes adds a string of zenid text to the product categories. For example......

http://www.fort777.co.za/index.php?main_page=index&cPath=1

is stored and loads as:-

http://www.fort777.co.za/index.php?main_page=index&cPath=1&zenid=bvuac71knms96vg2j0ss8ivdrce9u8iae4omjjck4c8b535ngsj0

Refreshing the home page often clears the additional text from all of the product categories urls and the site behaves as it should.

Does anyone have any suggestions as to how we can fix this problem?

Not sure what your "previous" experience was, but the zenid appears on the first page loaded and "disappears" after another page is loaded. It is part of a security system, where initially no token is engrained into the session, but once it is brought into the URI, it can then be captured and stay with the visitor throughout their visit.

So, yes you will see a zenid when first arriving at the page, and then on all of the properly formatted links from that page. After that, the zenid can be seen/found elsewhere, but is not part of the URI and this is normal.

This is not a problem; however, if you are having other actual functional issues you may want to inquire further and provide more information.

mc12345678:

So, yes you will see a zenid when first arriving at the page, and then on all of the properly formatted links from that page. After that, the zenid can be seen/found elsewhere, but is not part of the URI and this is normal.

If I open a second or third session in the same browser, then I agree, the zenid is no longer part of the url.

When you say that the zenid is present when first arriving at the (home) page, are you saying that it should ONLY be present in the home page url? My problem is that it appears in all of the various links (eg. any of the product categories) so instead of going 'say' to page 2, which might be our 'Newsletter' page, the link address is page2 PLUS the zenid text, which clearly isn't a valid url address.

Here is a typical example: "http://www.fort777.co.za/index.php?main_page=newsletter**&zenid=nn1p0ilr74tt3k9kgqgotlj2aioq5gur4m58pbg0i4kkfiin34r1**"

BlightyExPat:

If I open a second or third session in the same browser, then I agree, the zenid is no longer part of the url.

When you say that the zenid is present when first arriving at the (home) page, are you saying that it should ONLY be present in the home page url? My problem is that it appears in all of the various links (eg. any of the product categories) so instead of going 'say' to page 2, which might be our 'Newsletter' page, the link address is page2 PLUS the zenid text, which clearly isn't a valid url address.

Here is a typical example: "http://www.fort777.co.za/index.php?main_page=newsletter**&zenid=nn1p0ilr74tt3k9kgqgotlj2aioq5gur4m58pbg0i4kkfiin34r1**"

So, not sure why it is thought that a uri that contains more than one parameter (main_page is a parameter, that is followed by zen_id. If the "starting" point were a product in a category then there would be three initially, but if one were to move to the next or previous product from there (or in this case clicked on 3.5mm to 6.35mm to end up on the result) then an additional parameter would be added (zenid). See this as an example: ```
http://www.fort777.co.za/index.php?main_page=product_info&cPath=1_2_3_4_1457&products_id=9801

http://www.fort777.co.za/index.php?main_page=product_info&cPath=1_2_3_4_1398&products_id=9277&zenid=sessionCode

See, here's the process: customer opens a browser, types in the uri to the desired location (somewhere on your store), server(s) direct the customer to the page. A check is performed for a session token either in the uri or "inthe page" from where it came (POST data/hidden field data), if the session value is found, then aspects of the previous session if it is still alive are brought into the browser (ie, shopping cart contents) and the session's clock is restarted allowing it to live longer. If that session data is found in the uri either with a ? Or & in front of it then it is assigned to a hidden field on the page and removed from the uri for the next link location. If the session data is found in the hidden value of the previous page then it will remain as a hidden value.
If the session value doesn't exist in either the uri ($_GET[]) or the hidden value ($_POST[]) then the process is begun with attaching it to every ZC generated URI so that the above process can be performed. URIs that are hard coded will not gain the benefit of passing the session value (zenid) and so the system will ttempt to compensate which (and I think at this point I'm getting beyond my experience of review) should result in the same session value assuming that cookies worked and other checks that the software does, otherwise a new session may be begun and any session tracked aspects become "lost". 

Anyways, so the zenid will appear in the links of the first page visited (regardless if the home page or otherwise), and in the uri of the browser on the first click from the first page, and then as a hidden value on that second page and each subsequent page if ZC page design is followed especially if using zen_ related functions.

So back to the "issue"... What is it? Meaning, what is the issue or problem now that so much of that has been explained. There is information available on the topic; however, I was not quickly able to find what I was looking for. I know that the instructions for the plugin CEON Uri mappings provides some discussion on it/it used to be on the applicable website; however, after the passing of the original author (Connor Kerr), some things have not been maintained as they were.

The problem is that when you get the zenid added to the URL, you get a blank page and you have to use the "Back" button of the browser to go back and then try the link again. Then it works.

At the moment the site is running ZenCart v 1.5.0 and we are working on upgrading to 1.5.3.

When the site ran on the old server (openSUSE 11.x) this problem did not exist. Not sure if this due to the newer PHP version and if it will be resolved after the upgrade to 1.5.3 is complete.

Thanks

Three days ago there was no problem with the presence of the zenid in the uri at least as accessed using the above links. Don't know what has changed but when I tried just a few minutes ago, a 406 error was presented. A couple of other things: I made note of the zenid which was captured in the source page information as described in multiple locations. I then tried to follow a link: 406 error. Came back to the page, tried a different link: same error. It wasn't until I reloaded the page (in this case opened a new browser page) and went to a different uri without a zenid, the I was able to access another page. Review of the source code showed a new/different security token...

Somewhat tells me that there is a sessions issue.

Now, some other things: you're using the default classic folder as your active template directory and you do have programs/plugins that are template driven loaded... I know this because of the results/typical results of using one plugin in particular. That plugin is not considered to be a cuse of the problem, but it does indicate that there are plugins installed into the classic/clean templaate. Further it could mean that one of those plugins is causing this issue or it is an adjustment of settings. Like said, three days ago it worked just fine... Something changed at least from the side we see here on the internet. As for using a different directory, all that was needed was to copy the occasions of the /classic/ directory to the new directory name, then under the includes/templates/YOUR_TEMPLATE/ diirectory where the template_info file is, go into that and change the name of the template slightly so that when seeing the dropdown in the admin panel it maakes sense which template it is. :)

Otherwise, check with your host about server setup it seems that an internet search a 406 error supposedly is not something that can otherwise be corrected. (Of course if it is related to sessions, then there is some control over it.)

But you can access the admin pnel without any issue? It too uses a zenid when logging in... And following session timeouts.. Different parameter name, but still...

Suggest also running through the posting guidelines and answering those questions..

The admin side does not have this problem.

I will look at the plugins and server setup.

Thanks