Forum Moderators: coopster

Message Too Old, No Replies

SSL and sessions

         

Meno

1:39 pm on Feb 8, 2008 (gmt 0)

10+ Year Member



I have a shopping cart that uses sessions and cookies. When the user adds an item to his cart and clicks checkout, I have it send the user to the checkout page (which has ssl) by an absolute link: href="https://..."

My SSL certificate works fine. The problem is that, when the browser goes to the absolute address, it starts a new session and thinks the user's cart is empty.

Is the absolute link the problem? If so, is there some other way, such as header info, to cause a page to load up with the SSL?

PHP_Chimp

7:48 pm on Feb 8, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



When you use a link with http: or https: your browser will think that this is an external, completely different site. As will php.
So a new session will be started.
This is important so that you dont get a session carried over to another domain.
So either you will need to find a way to pass that session data over (you could use $_POST and serialize the data, however this is going to be unencrypted and publicly viewable, so not a good idea), write the session data to a file and have the https: site read the data from that file and populate a new session with this data, do all of the shopping on the https: server, or you could pass a unique id and shopping cart details (no personal details, thats what the unique id is to replace, use the session id if you like) over to the https: server in the form of GET or POST then have the https: server return a paid, canceled, failed response back to the http: server so that you dont need to pass any interesting information about unencrypted.

Meno

10:28 pm on Feb 8, 2008 (gmt 0)

10+ Year Member



Thanks Php_chimp. I thought that it was the absolute link that was doing it. It seems that the easiest way to do it is to send the user to the SSL server before any items are added to the cart.

barns101

4:54 pm on Feb 10, 2008 (gmt 0)

10+ Year Member



As far as I am aware using an absolute URL shouldn't make you lose your session. However, absolute URLs are not automatically rewritten to contain the SID. Also, remember that the session cookie only works on the domain that set it (i.e. going from domain.com to shop.domain.com will lose the session).

PHP_Chimp

9:14 pm on Feb 10, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



You just need to make sure that your session stays on the same domain. I think that you are probably correct in sending the people across to the https domain to do all of there shopping.

You can use absolute links and sessions, so long as the session stays in the same domain. So its not the link, its the change of domain that is the problem.

Meno

6:48 pm on Feb 11, 2008 (gmt 0)

10+ Year Member



Thanks, barns. It turns out that google sends the user "to [mysite.com,"...] but my absolute link goes to "https://www.mysite.com." Do you know what function I could use to force the 'www' domain prefix? I'm thinking parse_url or somthing like that might work...

[edited by: Meno at 6:56 pm (utc) on Feb. 11, 2008]

Achernar

7:10 pm on Feb 11, 2008 (gmt 0)

10+ Year Member Top Contributors Of The Month



If the domain and path are the same, a session cookie set in
http://example.com/path/page
will be available to
[example.com...]

The reverse is not necessarily true (I haven't tested, I don't know the default setting).

You can change the default behavior by modifying these PHP options:

session.cookie_path
session.cookie_domain
session.cookie_secure

Do you know what function I could use to force the 'www' domain prefix?

Assuming that you're using apache, add these rules in the configuration for the http://example.com site:

RewriteEngine on
RewriteRule ^(.*)$ http://www.example.com$1 [R=301,L]

Meno

8:29 pm on Feb 11, 2008 (gmt 0)

10+ Year Member



Thanks, Achernar. I put that in an htaccess, and it worked, except I had to put a '/' after the domain name. Just out of curiosity, what does [R=301,L] mean?

barns101

11:01 pm on Feb 11, 2008 (gmt 0)

10+ Year Member



Just out of curiosity, what does [R=301,L] mean?

The 301 means that the header code sent to redirect the visitor is code 301 (permanent redirect) and the L means that this is the last rule to check.

Achernar

1:33 am on Feb 12, 2008 (gmt 0)

10+ Year Member Top Contributors Of The Month



except I had to put a '/' after the domain name

Did you put the rules in the main apache config file or in the .htaccess file at the root of your domain?

Meno

1:47 am on Feb 12, 2008 (gmt 0)

10+ Year Member



I put them in an htaccess file at the root of my domain. Why?

Achernar

2:01 am on Feb 12, 2008 (gmt 0)

10+ Year Member Top Contributors Of The Month



This is why you had to add the '/'. ;)

Is the directory shared for both sites (www and non-www)?
If yes, the redirect is not breaking the 'www' site?

[edited by: Achernar at 2:03 am (utc) on Feb. 12, 2008]

Meno

2:11 am on Feb 12, 2008 (gmt 0)

10+ Year Member



Although I don't know for certain, I do believe the directory is shared for the www and non-www sites, considering that both display my content. I don't notice anything funny, but what exactly do you mean by is it "breaking" the site?

[edited by: Meno at 2:12 am (utc) on Feb. 12, 2008]

Achernar

2:16 am on Feb 12, 2008 (gmt 0)

10+ Year Member Top Contributors Of The Month



It means that by the rewrite rule that is also set for 'www' (if they share the directory), http://www.example.com/path will redirect to http://www.example.com/path with an external redirect (and it should do an infinite loop). Maybe apache is ignoring the rule when a URL redirects to itself.
If you can still access your site without problem, it should not bother you.

Meno

2:31 am on Feb 12, 2008 (gmt 0)

10+ Year Member



Well, to tell you the truth, it didn't work at first. I went to the apache web site and added this:
RewriteCond %{HTTP_HOST}!^www\.example\.com [NC]
RewriteCond %{HTTP_HOST}!=""
I don't know if this is what caused it to work. I have no idea if this is had anything to do with it.

Achernar

11:13 am on Feb 12, 2008 (gmt 0)

10+ Year Member Top Contributors Of The Month



You don't need the RewriteCond %{HTTP_HOST}!=""
and
RewriteCond %{HTTP_HOST}!^www\.example\.com [NC]
can be replaced by
RewriteCond %{HTTP_HOST} ^example\.com [NC]
or even by:
RewriteCond %{HTTP_HOST} =example.com [NC]

I don't know if this is what caused it to work. I have no idea if this is had anything to do with it.

Yup, this is what "fixed" the rewriterule. :)

[edited by: Achernar at 11:35 am (utc) on Feb. 12, 2008]