Cannot get rid of oscid in the URL

[knifeman]

My website is

here.

 

I have checked everything I can think of but the oscid is still in the URL no matter how many clicks I make. Would someone please check out the site and let me know if it is my machine or does everyone get endless ids.

 

Thanks,

 

Tim

[knifeman]

This is weird. If I enter the store, then go to the home page and reenter, then the oscid will drop off like it should. But if I enter from my bookmark to the catalog page and never leave the catalog, then the id stays in the URL.

 

Tim

[squeekit]

did you try sid killer?

[knifeman]

My host has been looking into this problem for me since it looks like everything in my files is correct. They sent this to me today.

I have added the following rules in the .htaccess file of 'wholesale.myknifestore.com' and it seem to be working fine now.
---------------------------------------------
# case: leading and trailing parameters
RewriteCond %{QUERY_STRING} ^(.+)&osCsid=[0-9a-z]+&(.+)$ [NC]
RewriteRule (.*) $1?%1&%2 [R=301,L]
#
# case: leading-only, trailing-only or no additional parameters
RewriteCond %{QUERY_STRING} ^(.+)&osCsid=[0-9a-z]+$|^osCsid=[0-9a-z]+&?(.*)$ [NC]
RewriteRule (.*) $1?%1 [R=301,L]
---------------------------------------------
Can you please check this.

Would some of the oscommerce experts please tell me what you think of this solution.

 

Tim

[skylla]

Jeez, why would you want to get rid of your URL appended sessionIDS or even go through great lenghts to destroy them? You talk about a problem and there's none.

 

They are an integral part of your shop, read up about them!! If cookies are disabled client side and since you have 'cookies enforced' disabled, you have rendered your shop useless.

[knifeman]

Jeez, why would you want to get rid of your URL appended sessionIDS or even go through great lenghts to destroy them? You talk about a problem and there's none.

 

They are an integral part of your shop, read up about them!! If cookies are disabled client side and since you have 'cookies enforced' disabled, you have rendered your shop useless.

I am admittedly not a php expert, but I have read up on sessions. Session id numbers are not supposed to show in the address bar after the 2nd or 3rd click. My store was working fine until something changed. My host has a habit of updating, upgrading and who knows what else without any notification. Sometimes the store gets broken. I don't think their suggestion is proper since it is adding code that should not have to be added. Since I have no other solution, I was asking for some opinions on the implications of the changes they are proposing.

 

I went to the site and added items to my cart, left the site and came back and the items were still in the cart, so I guess it is working this new way.

 

Tim

[skylla]

I am admittedly not a php expert, but I have read up on sessions. Session id numbers are not supposed to show in the address bar after the 2nd or 3rd click.

 

you and your source are wrong. period.

 

I went to the site and added items to my cart, left the site and came back and the items were still in the cart, so I guess it is working this new way.

 

Tim

 

not if you disable cookies in your browser

 

I will repeat myself once more: there was nothing wrong with your store to start with, you are on the wrong track and giving sessionIDs a bad name. Stop the crusade, give it a rest and try and befriend them.

[crash3903]

Your oscid's are an imperative part of your store - If you have a guest that adds products to their catalogue and then comes back 2 days later to buy those products and registers it is these id's that identify their products

 

***DO NOT REMOVE sId's****

 

The only downfall is that google may run around your site hence the phrase the google dance

 

use the sid killer as recommended but to do not remove sessions from the url

 

HTH

 

Mark

[boxtel]

My host has been looking into this problem for me since it looks like everything in my files is correct. They sent this to me today.

I have added the following rules in the .htaccess file of 'wholesale.myknifestore.com' and it seem to be working fine now.
---------------------------------------------
# case: leading and trailing parameters
RewriteCond %{QUERY_STRING} ^(.+)&osCsid=[0-9a-z]+&(.+)$ [NC]
RewriteRule (.*) $1?%1&%2 [R=301,L]
#
# case: leading-only, trailing-only or no additional parameters
RewriteCond %{QUERY_STRING} ^(.+)&osCsid=[0-9a-z]+$|^osCsid=[0-9a-z]+&?(.*)$ [NC]
RewriteRule (.*) $1?%1 [R=301,L]
---------------------------------------------
Can you please check this.

Would some of the oscommerce experts please tell me what you think of this solution.

 

Tim

 

your host is a moron.

[knifeman]

your host is a moron.

Hi Amanda,

 

Thank you for chiming in. I value your input as I have seen by your posts how knowledgeable you are in the oscommerce arena.

 

I have 2 stores besides the one mentioned in this topic. Both sites have the same behavior:

Enter the home page, no id in the URL.

Click anywhere and bam, you get an id number in the URL.

Click anywhere again and poof, the id number disappears.

Both sites are taking orders daily.

 

I am somewhat confused because I thought this was how it is supposed to work.

 

The code my host added to the htaccess file was copied from one of my other sites that is working "correctly". However, when they added it to this site, the id number is never visible. Skylla is correct if cookies are disabled the store won't work. I wish I knew where the code came from, because the other store that has it, is working.

 

I played with my cookie settings and I now see what was being said earlier about my store working all the time. If cookies are disabled on my working site the id number stays all the time. So maybe that is what was happening. If so, how would I enable cookies? I know how to change my settings in IE, but it won't take a subdomain. I have myknifestore.com set as allow. Does this automatically allow all subs from that domain?

 

Tim

[knifeman]

I finally found it. The code my host has copied from my other site, originally came from the Spider Session Remover mod.

http://www.oscommerce.com/community/contributions,2819/category,all/search,sid+killer

[boxtel]

Hi Amanda,

 

Thank you for chiming in. I value your input as I have seen by your posts how knowledgeable you are in the oscommerce arena.

 

I have 2 stores besides the one mentioned in this topic. Both sites have the same behavior:

Enter the home page, no id in the URL.

Click anywhere and bam, you get an id number in the URL.

Click anywhere again and poof, the id number disappears.

Both sites are taking orders daily.

 

I am somewhat confused because I thought this was how it is supposed to work.

 

The code my host added to the htaccess file was copied from one of my other sites that is working "correctly". However, when they added it to this site, the id number is never visible. Skylla is correct if cookies are disabled the store won't work. I wish I knew where the code came from, because the other store that has it, is working.

 

I played with my cookie settings and I now see what was being said earlier about my store working all the time. If cookies are disabled on my working site the id number stays all the time. So maybe that is what was happening. If so, how would I enable cookies? I know how to change my settings in IE, but it won't take a subdomain. I have myknifestore.com set as allow. Does this automatically allow all subs from that domain?

 

Tim

 

if your cookies are accepted then indeed the sid will be removed from the url as it is then stored in the cookie. If the cookie is not accpeted, it remains in the url as that is the only alternative. The sid will be in the first 2 pages as you cannot set and read a cookie on the same page. So it needs a new page request to determine if that cookie was set.

 

Unless you force cookies ofcourse which means that no session is ever started unless cookies are accepted.

Meaning that ALL session based functionality ceases to work, not just add to cart and login.

 

The code your host put in there will make sure that if cookies are not accepted, the sid is removed from the url at all times which has a similar effect as forcing cookies. It will function but ONLY if cookies are accepted, otherwise your store ceases to function just like forcing cookies but this time without even a warning.

It is very stupid symptom removal.

 

 

forget sid killer as it is an accident waiting to happen.

 

Bottom line, make sure your cookies are accepted first. Then the sid will be gone unless the user deliberately refuses cookies or has the security setting pretty high but that is beyond anybodies control.

And make sure you sent a P3P header which has the cookie privacy policy as IE on higher security levels requires it or it will refuse them.

[knifeman]

The code your host put in there will make sure that if cookies are not accepted, the sid is removed from the url at all times which has a similar effect as forcing cookies. It will function but ONLY if cookies are accepted, otherwise your store ceases to function just like forcing cookies but this time without even a warning.

It is very stupid symptom removal.

forget sid killer as it is an accident waiting to happen.

 

Bottom line, make sure your cookies are accepted first. Then the sid will be gone unless the user deliberately refuses cookies or has the security setting pretty high but that is beyond anybodies control.

And make sure you sent a P3P header which has the cookie privacy policy as IE on higher security levels requires it or it will refuse them.

 

Thanks for the good information. I will look into the P3P header.

 

I have had my htaccess file put back to the original. So now my site wholesale.myknifestore.com has the sid in the url all the time even if cookies are accepted. (except, if you enter the store click a couple times, leave the store and then return with the same browser window)

I have no plans to install sid killer. I do have remove spider sessions installed on a previous site that had sessions indexed and that is where the code came from.

 

Tim

[boxtel]

Thanks for the good information. I will look into the P3P header.

 

I have had my htaccess file put back to the original. So now my site wholesale.myknifestore.com has the sid in the url all the time even if cookies are accepted. (except, if you enter the store click a couple times, leave the store and then return with the same browser window)

I have no plans to install sid killer. I do have remove spider sessions installed on a previous site that had sessions indexed and that is where the code came from.

 

Tim

 

well, that remove spider sessions is a good piece of code. But that one first checks if it is a spider before executing the redirects. What you put up there is executed regardless.

The php version is better though as it identifies much more spiders than the htaccess version since it uses the spiders.txt file apart from the fact that it works on all servers.

 

I can see that your site is setting a session cookie so I suspect that it cannot read it back.

I am not very good with cookie subdomains, paths and what have you but it seems the only logical explanation. You could check by echoing out your $_COOKIE array to see if it reads anything back from the browser.

[knifeman]

I can see that your site is setting a session cookie so I suspect that it cannot read it back.

I am not very good with cookie subdomains, paths and what have you but it seems the only logical explanation. You could check by echoing out your $_COOKIE array to see if it reads anything back from the browser.

I am sorry but I am still kinda cut and paste. I have merged a couple contributions on my own, but still in kindergarten.

 

I created a php file called echo.php.

<?php
echo $_COOKIE;
?>

Then I uploaded here:

http://wholesale.myknifestore.com/whls/echo.php

I entered the site, clicked around a couple times to set the cookie, then went to echo.php and I get a white page with one word on it.

Array

Now I don't know what to do with this information. I am not really sure I created the exact echo statement that you referred to.

 

This site is not really intended for top placement in search engines. I use it for people that want to buy the products wholesale. So if I have to live with the sid always showing in the url, I can. I think the session will expire before it causes a privacy problem. I just hate it when something has a small glitch and does not work correctly.

 

Thanks,

Tim

[boxtel]

I am sorry but I am still kinda cut and paste. I have merged a couple contributions on my own, but still in kindergarten.

 

I created a php file called echo.php.

<?php
echo $_COOKIE;
?>

Then I uploaded here:

http://wholesale.myknifestore.com/whls/echo.php

I entered the site, clicked around a couple times to set the cookie, then went to echo.php and I get a white page with one word on it.

Array

Now I don't know what to do with this information. I am not really sure I created the exact echo statement that you referred to.

 

This site is not really intended for top placement in search engines. I use it for people that want to buy the products wholesale. So if I have to live with the sid always showing in the url, I can. I think the session will expire before it causes a privacy problem. I just hate it when something has a small glitch and does not work correctly.

 

Thanks,

Tim

 

Tim, $_COOKIE is an array just like $_GET and $_POST and you echo those out with:

 

print_r($_COOKIE);

 

you could just add it to application_top.

 

the construction I always use on live sites it using my own ip address.

 

I have a function in general.php:

 

function me() {

if (tep_get_ip_address() == 'MY_IP_ADDRESS') {

return true;

} else {

return false;

}

}

 

then whenever I want to put something in the live site that only I am supposed to see I use:

 

if (me()) {

print_r($_COOKIE);

}

 

And I will see the result but nobody else will.

[knifeman]

Tim, $_COOKIE is an array just like $_GET and $_POST and you echo those out with:

 

print_r($_COOKIE);

 

you could just add it to application_top.

 

Thanks Amanda,

 

I got it working and on the first page it just said "Array" at the top of the page. Then on every page after it had "Array ( [osCsid] => XXXXXXXXXXXXXXXXXXXX )"

 

Of course the actual sid was in the place of my Xs. I still find it weird that leaving the site and coming back will finally remove the sid, but staying in the store causes the sid to stay in the url. Probably something simple that I am overlooking.

 

Tim

[boxtel]

Thanks Amanda,

 

I got it working and on the first page it just said "Array" at the top of the page. Then on every page after it had "Array ( [osCsid] => XXXXXXXXXXXXXXXXXXXX )"

 

Of course the actual sid was in the place of my Xs. I still find it weird that leaving the site and coming back will finally remove the sid, but staying in the store causes the sid to stay in the url. Probably something simple that I am overlooking.

 

Tim

 

yes, this is a tricky one, that it has no content on the first page is understandable as you cannot set the cookie and read it on the same page. After it is set you get it back in the cookie array which is fine.

So it has to be somewhere else in the code where it determines that the cookie is accepted and as such should cease to add it to the url. I believe, in the back of my mind, that $SID is defined if it needs to be in the url and not defined if it does not.

I have no answer for you right now but I will have a look as to what might be causing this.

 

You could also echo out $SID to see what it contains as this code in tep_href_link determines whether the session id is attached:

 

// Add the session ID when moving from different HTTP and HTTPS servers, or when SID is defined

if ( ($add_session_id == true) && ($session_started == true) && (SESSION_FORCE_COOKIE_USE == 'False') ) {

if (tep_not_null($SID)) {

$_sid = $SID;

} elseif ( ( ($request_type == 'NONSSL') && ($connection == 'SSL') && (ENABLE_SSL == true) ) || ( ($request_type == 'SSL') && ($connection == 'NONSSL') ) ) {

if (HTTP_COOKIE_DOMAIN != HTTPS_COOKIE_DOMAIN) {

$_sid = tep_session_name() . '=' . tep_session_id();

}

}

}

[knifeman]

You could also echo out $SID to see what it contains as this code in tep_href_link determines whether the session id is attached:

I added the print sid command and the sid is displayed slightly different than with the previous command. The page now shows:

osCsid=XXXXXXXXXXXXXXXXXXXX

 

I will look through the code again to compare what you last posted. Thanks again,

Tim

[boxtel]

I added the print sid command and the sid is displayed slightly different than with the previous command. The page now shows:

osCsid=XXXXXXXXXXXXXXXXXXXX

 

I will look through the code again to compare what you last posted. Thanks again,

Tim

 

right, now if $SID is defined as such, then it has to be somewhere in the sessions class as there is where it is set. Does this system have a different php version by any chance?

[knifeman]

right, now if $SID is defined as such, then it has to be somewhere in the sessions class as there is where it is set. Does this system have a different php version by any chance?

This site has 4.4.4

My other 2 sites that are working are 4.4.2 and 4.4.4, however these are both installed in the root.

 

Just to make sure you realize the Xs posted in my last post are mine. I replaced the actual sid in my post. Probably is not necessary, but I did it anyway.

 

Tim

[boxtel]

This site has 4.4.4

My other 2 sites that are working are 4.4.2 and 4.4.4, however these are both installed in the root.

 

Just to make sure you realize the Xs posted in my last post are mine. I replaced the actual sid in my post. Probably is not necessary, but I did it anyway.

 

Tim

 

I already assumed you would have, otherwise I would have asked you what the h... those X's are.

Still, I will have to check this but as far as my memory serves me, I thought that the session class was only used if the php version was something like 4.3 or something like that.

 

like in application top it says (on a default install):

 

// check if sessions are supported, otherwise use the php3 compatible session class

if (!function_exists('session_start')) {

define('PHP_SESSION_NAME', 'osCsid');

define('PHP_SESSION_PATH', $cookie_path);

define('PHP_SESSION_DOMAIN', $cookie_domain);

define('PHP_SESSION_SAVE_PATH', SESSION_WRITE_DIRECTORY);

 

include(DIR_WS_CLASSES . 'sessions.php');

}

 

 

 

and as far as I can see, there is no other code which defines $SID.

 

So it must be a php version issue, somehow.

[knifeman]

I already assumed you would have, otherwise I would have asked you what the h... those X's are. :thumbsup:

Still, I will have to check this but as far as my memory serves me, I thought that the session class was only used if the php version was something like 4.3 or something like that.

 

 

So it must be a php version issue, somehow.

Amanda,

 

Thanks for helping out on this one. I have felt all along it is something my host has changed. Most of my store problems have come from their end. Not sure about my next step yet. Just for the heck of it, here is part of application_top

// check if sessions are supported, otherwise use the php3 compatible session class
 if (!function_exists('session_start')) {
define('PHP_SESSION_NAME', 'osCsid');
define('PHP_SESSION_PATH', $cookie_path);
define('PHP_SESSION_DOMAIN', $cookie_domain);
define('PHP_SESSION_SAVE_PATH', SESSION_WRITE_DIRECTORY);

include(DIR_WS_CLASSES . 'sessions.php');
 }

// define how the session functions will be used
 require(DIR_WS_FUNCTIONS . 'sessions.php');

// set the session name and save path
 tep_session_name('osCsid');
 tep_session_save_path(SESSION_WRITE_DIRECTORY);

// set the session cookie parameters
  if (function_exists('session_set_cookie_params')) {
session_set_cookie_params(0, $cookie_path, $cookie_domain);
 } elseif (function_exists('ini_set')) {
ini_set('session.cookie_lifetime', '0');
ini_set('session.cookie_path', $cookie_path);
ini_set('session.cookie_domain', $cookie_domain);
 }

// set the session ID if it exists
  if (isset($HTTP_POST_VARS[tep_session_name()])) {
 tep_session_id($HTTP_POST_VARS[tep_session_name()]);
  } elseif ( ($request_type == 'SSL') && isset($HTTP_GET_VARS[tep_session_name()]) ) {
 tep_session_id($HTTP_GET_VARS[tep_session_name()]);
  }

Later this evening I will dig deep and start comparing code from one site to the other.

 

Tim

[boxtel]

Amanda,

 

Thanks for helping out on this one. I have felt all along it is something my host has changed. Most of my store problems have come from their end. Not sure about my next step yet. Just for the heck of it, here is part of application_top

// check if sessions are supported, otherwise use the php3 compatible session class
 if (!function_exists('session_start')) {
define('PHP_SESSION_NAME', 'osCsid');
define('PHP_SESSION_PATH', $cookie_path);
define('PHP_SESSION_DOMAIN', $cookie_domain);
define('PHP_SESSION_SAVE_PATH', SESSION_WRITE_DIRECTORY);

include(DIR_WS_CLASSES . 'sessions.php');
 }

// define how the session functions will be used
 require(DIR_WS_FUNCTIONS . 'sessions.php');

// set the session name and save path
 tep_session_name('osCsid');
 tep_session_save_path(SESSION_WRITE_DIRECTORY);

// set the session cookie parameters
  if (function_exists('session_set_cookie_params')) {
session_set_cookie_params(0, $cookie_path, $cookie_domain);
 } elseif (function_exists('ini_set')) {
ini_set('session.cookie_lifetime', '0');
ini_set('session.cookie_path', $cookie_path);
ini_set('session.cookie_domain', $cookie_domain);
 }

// set the session ID if it exists
  if (isset($HTTP_POST_VARS[tep_session_name()])) {
 tep_session_id($HTTP_POST_VARS[tep_session_name()]);
  } elseif ( ($request_type == 'SSL') && isset($HTTP_GET_VARS[tep_session_name()]) ) {
 tep_session_id($HTTP_GET_VARS[tep_session_name()]);
  }

Later this evening I will dig deep and start comparing code from one site to the other.

 

Tim

 

Tim, keep me posted, I hate it when things do not work as they should.

[knifeman]

Tim, keep me posted, I hate it when things do not work as they should.

 

I will Amanda. I have been thinking of moving the site to the root. I may do that now just to see what happens. Thanks for all your help.

 

Tim