SSL and Cookies

[yelir]

Hi, I am trying to use a shared SSL certificate on with my installation. The links appear to show up fine, but always force me to the Cookie Usage page. When SSL is disabled it works fine. I've looked through all the forums and can't find any similar problems. Could this be a problem with the shared SSL being able to write somewhere. The relevant info in my configure.php is as follows:

 

  define('HTTP_SERVER', 'http://www.accurate1.com');
 define('HTTPS_SERVER', 'https://telesto.site5.com/~accurate1'); 
 define('ENABLE_SSL', true); 
 define('HTTP_COOKIE_DOMAIN', 'www.accurate1.com');
 define('HTTPS_COOKIE_DOMAIN', 'telesto.site5.com/~accurate1');
 define('HTTP_COOKIE_PATH', '/catalog/');
 define('HTTPS_COOKIE_PATH', '/catalog/');
 define('DIR_WS_HTTP_CATALOG', '/catalog/');
 define('DIR_WS_HTTPS_CATALOG', '/catalog/');

 

 

Thanks very much ahead of time :)

 

PS - Is there any better way to search these forums or any tips on searching? The search results on here seem to always be quite bad and off, and it looks like many people have this problem based on the numerous duplicate posts.

[♥ecartz]

I would try changing to

  define('HTTPS_COOKIE_DOMAIN', 'telesto.site5.com');
 define('HTTPS_COOKIE_PATH', '/');

and see if that works. You also may want to set the tep_href_link function to include the session ID when transferring from non-SSL to SSL.

 

Hth,

Matt

[yelir]

Thanks very much, I modified the configure.php file and that seemed to get rid of the cookie problem.

 

I'm a bit confused as to how to do the second part (set the tep_href_link to include session ID when transferring to SSL). Do I have to modify the code or is there a configuration value? I've looked through configuration I can't see anything?

 

Thanks.

[♥ecartz]

If it's working, then you don't need to do it. :) It would be a code modification though.

 

Hth,

Matt

[pickled]

I'm also having troubles getting cookies to be consistent in http and https pages.

 

my configuration is:

define('HTTP_SERVER', 'http://www.mydomain.com');

define('HTTPS_SERVER', 'https://mydomain.sslpowered.com');

define('ENABLE_SSL', true); // secure webserver for checkout procedure?

define('HTTP_COOKIE_DOMAIN', 'mydomain.com');

define('HTTPS_COOKIE_DOMAIN', 'mydomain.sslpowered.com');

define('HTTP_COOKIE_PATH', '/');

define('HTTPS_COOKIE_PATH', '/');

 

This isn't working, and the login page gives "cookies required"

 

When I do the modification suggested in http://www.oscommerce.com/forums/index.php?sho...=0entry278344 by iiiNetworks (Matt), to force the session ID to be passed when switching back and forth between http and https when using cookies ....

 

========================================

(around line 45 of includes/functions/html_output.php)

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

to

if ( ($add_session_id == true) && ($session_started == true) ) {

If that helps, then someone should file a bug report.

==========================================

 

.... that does seem to make things work. But I'd really like to know why the modification isn't always needed. Is there something about my configuration, or the way my host provides ssl that makes it necessary?

 

 

The reason I'm asking is I am having ENORMOUS problems, because I'm running osCommerce in a frame and trying to get P3P working so that IE6 doesn't reject cookies when I switch to the https pages (because it decides that's a 3rd party page, and wants a P3P compact policy). I've been struggling with this for about 4 days now, and decided to go back to basics and understand exactly what is going on with sessions, cookies and SSL.

 

thanks very much, anyone,

 

James

[yelir]

Hi,

 

Changing my configuration as you said(ecartz) gets rid of my cookie problem, but the cart (session) is not passed to the SSL session. Do I need to modify my code as above, or can I just change the cart to use cookies in the database? Are there any problems to putting cookies in the database?

Thanks

[♥ecartz]

Sessions you mean? Apparently some servers have problems with sessions in the database, but it is the recommended way to store sessions on a shared server. I.e. there are usually no problems with storing sessions in the database.

 

Cookies are going to be stored on the customer's computer; that's what a cookie is (info stored by the browser).

 

Hth,

Matt

[yelir]

Sorry, yah I meant sessions. I didn't know but by looking into my configuration they are already stored in the database :blink: ...

 

What code changes would you recommend to fix this then? Is it just the 1 change to 'html_output.php' linked to in this thread?

 

Thanks a lot..

[pickled]

Just FYI, I've now been testing for about a week with the one line change described earlier to pass the Session ID when switching back and forth between SSL and NONSSL. It seems to be working well, and the code makes sense. The only thing I can't understand is how it could possibly work without this change.

 

James

[yoko]

Just FYI, I've now been testing for about a week with the one line change described earlier to pass the Session ID when switching back and forth between SSL and NONSSL. It seems to be working well, and the code makes sense.

Thanks Pickled, it was a solution for my problem, too!

[AlanR]

OK, I don't get it.

 

To summarize the solution:

-----

Change the https cookie path to '/'

Alter the line in html_output.php to ignore 'SESSION_FORCE_COOKIE_USE'

-----

 

So how is altering the line in html_output.php any different than going to admin/sessions and setting Force Cookie Use to true?

 

What you're doing is hacking the files so as to ignore session info stored in the db.

[pickled]

Firstly, I'm not absolutely sure on this.... that's why I'm proceeding pretty cautiously.....

With my SSL provider the domain is

mydomain.sslpowered.com

for SSL and

mydomain.com

for NONSSL, so the SSL domain is not a "sub-domain" of mydomain - as it would be if it was

ssldomain.mydomain.com

 

So, (even) with cookies on (and without the 1 line mod), when the first page loads in NONSSL, a session is created, cookie created (and the session stored with it) and other important variables are then all linked with that session ID.

Then, when user goes to an SSL page (for login), it's on a different domain, so another session ID is created, a new cookie created, and information is linked to that session ID - for example the important customer ID.

Then (and this is where the problem occurs) when user switches back to NONSSL, everything switches back to the first (NONSSL) cookie and session with completely different variable values associated with it - especially no customer ID. So the user is still effectively unknown by the NONSSL pages.

 

The one line mod, forces the session ID to be passed over when the switch is made from NONSSL to SSL (and back), forcing the session and cookie information to be synchronized. The session info in the database sessions table is still used. Just now you have the same session ID for both SSL and NONSSL.

 

I'm pretty confident about what is happening with the session IDs and variables such as $customer_id - as I debugged that all through. My nervous bit is my assumption that the problem occurs due to my ssl provider's domain naming convention. And my growing confidence in the "fix" comes from a week's testing and looking at more posts by this iiiNetworks Matt fella, who seems pretty knowledgable. There's also another Matt (ecartz) who talked about a one line fix who also seems pretty cluey. And I've tried every configuration in the configuration file I can think of and cannot get the consistency across SSL and NONSSL working. So, unless someone (probably called Matt) can say the fix/hack is no good, then I have to go with it.

[AlanR]

Firstly, I'm not absolutely sure on this.... that's why I'm proceeding pretty cautiously.....

With my SSL provider the domain is mydomain.sslpowered.com for SSL and mydomain.com for NONSSL, so the SSL domain is not a "sub-domain" of mydomain - as it would be if it was ssldomain.mydomain.com

OK, that makes sense. The directory structure you're forced to use is unusual.

 

Mostly you'll find ssl proxies like securexyz/mydomain.com or in some cases something like https://ssl.hosting.provider/catalog