Back to Part 2

——-

The HTTPS session is the “authority” session, and due to authenticity tests will not accept the HTTP session data as being “valid” as it doesn’t contain the correct information that an HTTPS session data file contains. So while it may still be possible for a user to hi-jack the HTTP session, it’s not possible for them to gain access to another users account or personal information by tampering with the HTTP headers and sending someone’s session id, because once they hit a page or perform an operation which pushes them to the HTTPS website, they immediately become logged out, and any personal information is cleared from the session data. For a user to hi-jack another visitors HTTPS session they’d need to have the ability “sniff” the secure session id, which is sent over the network in an encrypted fashion and is very unlikely – which is just as safe as always using HTTPS.  Read more... (333 words, 1 image, estimated 1:20 mins reading time)

Back to Part 1

——-

So what happens when the visitor is finished logging in, or has even completed a purchase at the HTTPS website and is pushed back to the HTTP website? Their browser no longer sends the same cookie data to the server because their browsing an entirely different domain. So how is the HTTP website suppose to know which items were just purchased, or that the user is logged in, or what items are in the visitors cart since they might have just completed a purchase? It can’t, that means you have to take session handling to a whole new level and synchronize the data that both the HTTP and HTTPS sessions contain. If you use simple TSID, then you could potentially pass the session id from the HTTP website to the HTTPS website the first time the visitor is pushed there. There is just one MAJOR problem with that, and that’s called session hijacking.  Read more... (368 words, 1 image, estimated 1:28 mins reading time)

A secure e-commerce store can only really be secure if transactions occur over a secure connection, such as SSL (HTTPS). Since SSL Security Certificates can be quite costly to purchase and time consuming to setup, sometimes it makes sense to “share” them across multiple solutions. But there’s a problem there: an SSL Cert will only work at the domain for which it was registered. So how do you get around that little issue if you still want to have a fully SEO friendly website, with it’s own unique domain name, where visitors can read your content, add products to their carts, post comments, but also perform secure actions like making purchases, saving personal data, ect.?  Read more... (283 words, 1 image, estimated 1:08 mins reading time)