Session ID

[Fredrik.r]

For some how I managed to remove SID in my first store, Under.se. I can't remember how though. Im at this moment producing two more stores but they seem to use sid numbers. I've turned off everything under "sessions" in admin (false) except "Prevent known spiders from starting sessions" but still i get sid-numbers..

 

1, Is it safe to use "prevent known spiders.." so that Google does not show sid-numbers?

 

2, What is the easiest way to remove sid-numbers?

Is that going to affect my stores functionality?

 

 

Thanks

[♥Vger]

The only way to turn session ids off is to run your store without ssl, or use a full ssl certificate. Then you can turn on the 'Force Cookie Use' feature, which will turn off session ids. Unfortunately, if you use a shared ssl then the two domains won't match and everyone will get sent to the Cookie Usage page.

 

Turning on 'Prevent Spider Sessions' won't hinder the spiders visting your site, but it will stop those spiders in the includes/spiders.txt file from generating session ids.

 

Vger

[Fredrik.r]

Ok, then it's ok, as long as Google doesnt show them. But how did I managed to remove them at this store without using SSL? :)

(I can't see the sessions id's in the url and the store functionality is just fine..)

[Fredrik.r]

(Did not see an edit button above..)

 

Regaring the store above, its running without SSL, and with 'Force Cookie Use' off, but still i can't see the sessions ids.

[♥Vger]

You don't see a session id on the homepage, but once you move to a product page (on your site) this is what you see

 

http://www.under.se/catalog/index.php?cPat...b5f11b3e8eefc2e

 

Vger

[stevel]

The only way to turn session ids off is to run your store without ssl, or use a full ssl certificate.  Then you can turn on the 'Force Cookie Use' feature, which will turn off session ids.

I know what you're trying to say here, but you're muddying the waters... Here's my attempt at explaining.

 

You can't do away with session IDs entirely, in that something needs to be passed from page to page to identify the session. In the usual case,a cookie gets set with the session ID and the ID disappears from URLs after the second page. (It's somewhat puzzling to me that it shows on the second page, I'd think this could be avoided, but anyway...)

 

If you enable Force Cookie Use, the cookie gets set right away and you never see the ID in the URL. The problem with this, as Vger mentions, ioccurs when you want to transition from non-SSL mode to SSL mode, such as when the customer goes to check out.

 

By design, a site can read only those cookies belonging to its domain. With fiull SSL, this is no problem, because the domain is the same between non-SSL and SSL pages. But with shared SSL, your SSL domain is different from the non-SSL domain, so cookies can't cross over. This is why, even when a cookie is set in the normal case, the session ID reappears on links to the HTTPS pages, as that is the only way to make the connection.

 

Unfortunately, Force Cookie Use is unforgiving and does not make allowances for the cookie domains being different (allowing the session ID to appear in the URL when required.) This is why you can't enable Force Cookie Use if you're using shared SSL.

 

In any event, you need to ensure that the xxx_COOKIE_DOMAIN defines have values that are the domains of the corresponding xxx_SERVER defines. Note that this really means domains, not URLs! For example, a store with a HTTP_SERVER of 'http://www.oscommerce.com' would have a HTTP_COOKIE_DOMAIN of 'oscommerce.com'. It is a common mistake for people to put a URL in there. Also, the HTTPS_COOKIE_DOMAIN has to match the domain of HTTPS_SERVER, which will be dffferent if shared SSL is being used.

[♥Vger]

I know what you're trying to say here, but you're muddying the waters... Here's my attempt at explaining.

 

19 lines later - you succeeded in explaining to those who are already tech savvy. Great explanation, but I think my two-liner was all that was needed.

 

You are wrong by the way about not being able to use the Force Cookie Use feature on a shared ssl - at least with some server setups. I didn't want to have to go into this - but here goes.

 

Say someone signs up for hosting and wants immediate access to a domain that's only just been added to a server - they get a temporary address, as in

 

http://servername.hostname.com/yourdomain.com

 

This is the same pathway as for a shared ssl cert for that domain, except change the http to https.

 

So, someone comes to the site on the normal http://yourdomain.com, but in the configure.php files the http pathway is set to http://servername.hostname.com/yourdomain.com, and this is where they go to as they start to navigate around the site. This matches the https pathway for the shared ssl, and so the shared ssl works.

 

Sorry - that came to 14 lines, a bit lengthy.

 

Vger

[Guest]

ahhh I love these forums!

 

humor, and information all at the same time!

 

Thank you both for the information, and for sheading some light on the subject for me.

 

RavenWulf

 

19 lines later - you succeeded in explaining to those who are already tech savvy.  Great explanation, but I think my two-liner was all that was needed.

 

You are wrong by the way about not being able to use the Force Cookie Use feature on a shared ssl - at least with some server setups.  I didn't want to have to go into this - but here goes.

 

Say someone signs up for hosting and wants immediate access to a domain that's only just been added to a server - they get a temporary address, as in

 

http://servername.hostname.com/yourdomain.com

 

This is the same pathway as for a shared ssl cert for that domain, except change the http to https.

 

So, someone comes to the site on the normal http://yourdomain.com, but in the configure.php files the http pathway is set to http://servername.hostname.com/yourdomain.com, and this is where they go to as they start to navigate around the site.  This matches the https pathway for the shared ssl, and so the shared ssl works.

 

Sorry - that came to 14 lines, a bit lengthy.

 

Vger

<{POST_SNAPBACK}>

[kmarkeg]

Hi all,

 

I hope that one of you still are monitoring this old tread.

 

I have 3 shops on a server with shared SSL so I can't use the Force Cookie Use feature.

 

My problem is that customers are copying the url (including the Session ID)

and post then out on forums, resulting in that many new customers is browsing with the same Session ID and then the problem appears.

 

Is the are contribution, fix or anything that I can do so that all new customers are force to change session ID? Based on mismatch in IP address, browser ID etc from the originale session ID.

 

I'm banging my head in the wall right now, so any help would be great.

 

Thanks

Knut

[stevel]

Well, you CAN enable the various "Check" options in admin under Sessions, but all of them cause problems for some legitmate customers. Check User Agent is probably the safest.

 

Why are the session IDs staying in your URLs? Do you not have the COOKIE_DOMAIN values set right?

 

You could replace this code in includes/functions/sessions/php:

  if (STORE_SESSIONS == 'mysql') {
if (!$SESS_LIFE = get_cfg_var('session.gc_maxlifetime')) {
  $SESS_LIFE = 1440;
}

with:

$SESS_LIFE = 600;

This will somewhat shorten the lifetime of inactive sessions, but it's not really a cure to your problem.

[kmarkeg]

Seams like you put me on the right track.

 

I have one server with 4 domains

1 domain that is made for SSL, and have an shared ssl cert.

file structure ..../sharedssldomain

 

and three main domains located (files based) on the same server at

.../sharedssldomain/maindomain1

.../sharedssldomain/maindomain2

../sharedssldomain/maindomain3

 

Meaning www.sharedssldomain.no/maindomain1 and www.maindomain1.no is pointing to the same folder, on the same server.

 

This was my previous config

define('HTTP_COOKIE_DOMAIN', 'www.sharedssldomain.no/maindomain');

define('HTTPS_COOKIE_DOMAIN', 'www.sharedssldomain.no/maindomain');

This gave me an SID on every page.

 

By changing to

define('HTTP_COOKIE_DOMAIN', 'www.maindomain.no');

define('HTTPS_COOKIE_DOMAIN', 'www.sharedssldomain.no/maindomain');

(pointing to the same physical folder on the same server)

With this config my http pages is working correctly, and only showing SID on the first page

 

My https pages is still displaying the SID, but I do not care since 99% of my problems are gone.

If you find anything wrong in the below config, please let me know

 

define('HTTP_SERVER', 'http://www.maindomain.no');

define('HTTPS_SERVER', 'https://www.sharedssldomain.no');

define('HTTP_COOKIE_DOMAIN', 'www.maindomain.no');

define('HTTPS_COOKIE_DOMAIN', 'www.sharedssldomain.no/maindomain');

define('HTTP_COOKIE_PATH', '/');

define('HTTPS_COOKIE_PATH', '/maindomain/');

define('DIR_WS_HTTP_CATALOG', '/');

define('DIR_WS_HTTPS_CATALOG', '/maindomain/');

 

Thanks

Knut

[stevel]

Almost right. You want:

 

 define('HTTP_COOKIE_DOMAIN', 'www.maindomain.no');
define('HTTPS_COOKIE_DOMAIN', 'www.sharedssldomain.no');

 

Since you have disguised your domain, I want to emphasize that it is crucial that the COOKIE_DOMAIN defines match the hostname/domain of the corresponding _SERVER defines. No folder paths. If there is no www in HTTPS_SERVER don't add it to HTTPS_COOKIE_DOMAIN.

[kmarkeg]

Ok.

 

Thanks for you help