Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

SSL login


dbl07

Recommended Posts

I have been looking at OSC's login script and I am confused about something.

 

If the session registers the stuff like the customer's first name under SSL why is the regular (non-SSL) site able to read that information?

 

In my case the SSL domain and the HTTP domain are different. I thought that session variables set under one domain couldn't be read by other domains.

 

Hope you can help!

 

Dbl07

Shaken! ... not stirred!

Link to comment
Share on other sites

You can "see" it because the information is in the database. It get sent there via SSL but, you can retrieve it via http if you know what to ask (mySQL query)

Link to comment
Share on other sites

I don't have configure.php set to save the session in the database. (i.e. STORE_SESSIONS is set to '<blank>'.

 

Does it store the session there anyway?

 

Dbl07

Shaken! ... not stirred!

Link to comment
Share on other sites

I belive that with your settings it would store the sessions in the dB by default....Did you look???

 

Why are you worried about it?

Link to comment
Share on other sites

I'm trying to write a login for the admin site.

 

The problem I'm having is that the login is over a different SSL domain than my HTTP domain.

 

When a specific session varaiable doesn't exist it redirects the user to the login page. This is a problem because the session variable is set for the secure server and can't be seen by the http server.

 

This is why I was wondering how OSC does it cause it works there.

 

Any suggestions?

 

Dbl07

Shaken! ... not stirred!

Link to comment
Share on other sites

  • 5 months later...
I don't have configure.php set to save the session in the database. (i.e. STORE_SESSIONS is set to '<blank>'. Does it store the session there anyway?

 

No, it stores them in files on your server. By default, it's the root /tmp directory if memory serves. I just happen to find it easier to store sessions in the database and they then have no chance of getting mixed up with other sites' sessions on the same server that write session files to the same directory. If you're going to keep the sessions in the files, I would suggest changing the path to something inside your own directory for that reason.

 

Additionally, why don't you just run then entire admin through SSL? There really aren't many graphics (buttons/icons) so the performance isn't too bad and in essence, everything you do in there is basically stuff you want to keep secure anyway. It would also solve your problem of the http server not reading the https variable (because it would all be https :) )

 

I run my whole admin through SSL and don't even think twice. In the admin configure, just make both HTTP and HTTPS server defines your SSL server/path and there will be no switching back and forth between nonssl and ssl no matter what the parameter calls for in the links.

 

I'm interested in dlb07 question also. How does the session get transfeered when ssl and nonssl are on physically different servers?

If just the domains are different (like shared SSL), the use of cookies alone is impossible because one domain can't read the other domain's cookie to get the session ID. You can easily append the session ID to the URL when switching between domains to keep the session from one to the other. In fact, OSC appends the SID to the URL automatically when switching between http/https on different domains for shared SSL situations. It's handled in the tep_href_link function.

 

If it's not just different domains, but really physically different servers, appending the SID should work the same way, but you would *have* to store the sessions in the DB rather than the default handling.

 

HTH

Link to comment
Share on other sites

The session ID needs to be passed when moving back and forth between NONSSL and SSL on a shared environment. OSC handles this by default in catalog/includes/functions/html_output.php, the tep_href_link function. If you go to that file, the 2nd or 3rd function is tep_href_link and you will see the append $sid section in it.

 

So, the first thing you will want to check is when going from the main domain to the SSL domain (like to login) or from SSL back to NONSSL, that there is an osCsid=xxxxx... appended to the URL after the switch is made. That's how the two servers keep the sessions between them.

 

If the SID is not there when going from one to the other, the problem lies elsewhere...

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...