zen id and blank pages for first view...

[gabiosz]

Hi,

We are getting an issue with our website, when you initially visit the site, the first time you move from the home page the ZEN ID shows in the address bar and the page is blank! Reloading the page won't fix it either, you need to go back and then click the link again. It's obviously something to do with the sessions, but I'm not sure how to go about fixing it, any ideas?

I am running v1.3.6 patch 1

Thanks!

[barricades]

Can you post the url so people can see the problem in action.

[DrByte]

You *really* need to upgrade ASAP. Your old version was released in October 2006, and has well-known security vulnerabilities.
Plus, most troubleshooting advice is geared around current versions, making it hard to assist you. Such as this one ... which points you to troubleshooting tools that are built-in since 2010 when v1.3.9 was released: http://www.zen-cart.com/content.php?124-blank-page
And hundreds of bugfixes have been included in versions released after yours.

[gabiosz]

You *really* need to upgrade ASAP. Your old version was released in October 2006, and has well-known security vulnerabilities.
Plus, most troubleshooting advice is geared around current versions, making it hard to assist you. Such as this one ... which points you to troubleshooting tools that are built-in since 2010 when v1.3.9 was released: http://www.zen-cart.com/content.php?124-blank-page
And hundreds of bugfixes have been included in versions released after yours.

I would love to but we have made WAY too many small modifications to our site, updating would simply break our site and undo everything. We will rebuild the whole site next year in any case. I'm just looking for a fix in the mean time.

[gabiosz]

It's actually not entirely a blank page but a 406 error. I noticed this while trying it in IE9 rather than Firefox.

Having hear that there are a lot of security vunerabilities, I'm not reluctant to share my URL

[RodG]

It's actually not entirely a blank page but a 406 error. I noticed this while trying it in IE9 rather than Firefox.

406 errors are often the result of something triggering Apache's mod_security rules.
The best (only?) way to solve this is to work with you host to see exactly what it is that is triggering the error.

Having hear that there are a lot of security vunerabilities, I'm not reluctant to share my URL

I assume you meant to say that you ARE reluctant to share your URL, and in this case I fully agree with you. The script kiddies do follow these forums looking for vulnerable sites that are publicly advertised as such. If you must share your URL do so in PM only. Personally I don't think it'll be of any help to us anyway.

As DrByte stated, your version is really old, which is going to make it very difficult to debug without a lot of information that isn't available to us (and some will only be available to your host).

The important thing in finding a fix though, is trying to determine what got changed to have caused to problem. You may well be using old code, but it isn't as though the code will 'wear out' - *something* must have changed recently in order to cause this (assumedly) recent problem. If you didn't change anything, then your host did. Ask them!

Cheers
Rod

[gabiosz]

406 errors are often the result of something triggering Apache's mod_security rules.
The best (only?) way to solve this is to work with you host to see exactly what it is that is triggering the error.



I assume you meant to say that you ARE reluctant to share your URL, and in this case I fully agree with you. The script kiddies do follow these forums looking for vulnerable sites that are publicly advertised as such. If you must share your URL do so in PM only. Personally I don't think it'll be of any help to us anyway.

As DrByte stated, your version is really old, which is going to make it very difficult to debug without a lot of information that isn't available to us (and some will only be available to your host).

The important thing in finding a fix though, is trying to determine what got changed to have caused to problem. You may well be using old code, but it isn't as though the code will 'wear out' - *something* must have changed recently in order to cause this (assumedly) recent problem. If you didn't change anything, then your host did. Ask them!

Cheers
Rod

Sorry, yes, I meant that I am reluctant to share the URL knowing that there are potential issues. I'm not sure it would help in any case, as you rightly point out it seems to be an Apache/PHP thing.

It seems to have started when we added a display in stock only filter, which appends the URL with: ?stock_filter=in_stock
, but i can't be sure, I'll have to disable this and check again.

Our site has been so heavily modified at a code level, there's just no hope of bringing it up to date at this stage.

[kobra]

there's just no hope of bringing it up to date at this stage.

Best to do it on your schedule versus getting hacked and being down while you then have to clean it up and then upgrade it

[gabiosz]

I hear what everyone is saying, and a new site is already in the making, in the mean time I have managed to fix this issue.

For reference, the includes/application_top.php includes a parameter check that will throw up a 406 error if the URL sting exceeds 43 characters. A bit short with more modern hash lengths, especially if you have some additional parameters appended to the URL.

On line 25 (in my version) of the includes/application_top.php, it shows

if (isset($_GET[$key]) && strlen($_GET[$key]) > 43) {

Change 43 to a more suitable higher number and the 406 error disappears for me.

[DrByte]

Keep in mind that changing that number arbitrarily is foolish. Changing it to a SPECIFIC value for SPECIFIC reason and NO LARGER THAN ABSOLUTELY NEEDED is key. Otherwise it totally defeats the purpose of that whole section of code, which is intended to minimize abuse and improve performance even when under attack.