I'm fully aware that the recommended practice is to just force SSL on the entire site. However, there are certainly unique cases where being able to pick and choose between HTTP and HTTPS could come in handy.
I was running into a similar scenario as @Dsavid Gardner. My company uses a third party vendor to manage our store portion of our site, and that store resides on the subdomain "https://store.mysite.com". We have 15 years worth of video content, and our current video management vendor breaks when a video is embedded in an SSL. (I'm guessing it's pulling in resources from HTTP domains, but that's another problem for another day)
Sure, I could purchase an SSL and go through the process of debugging two, third-party vendors, as well as doing a search and replace on our entire database (or an .htaccess file hack, but I digress) to correct any HTTP resource links, just to be able to have a message in the header say "Welcome 'YourName'", but that just seems like overkill.
Here's a simple Javascript solution that I came up with that sets a site-wide, insecure cookie based off of the secure cookies that are already set.
First, I grabbed some javascript cookie functions. Go ahead and put this code in the secure portion of your site:
function readCookie(name) {
var nameEQ = name + "=";
var ca = document.cookie.split(';');
for(var i=0;i < ca.length;i++) {
var c = ca[i];
while (c.charAt(0)===' ') {
c = c.substring(1,c.length);
}
if (c.indexOf(nameEQ) === 0) {
return c.substring(nameEQ.length,c.length);
}
}
return null;
}
function setCookie(cname, cvalue, exdays) {
var d = new Date();
d.setTime(d.getTime() + (exdays*24*60*60*1000));
var expires = "expires="+d.toUTCString();
/* Note, the W3 documents where I got this code didn't include the
option to set the domain. I added this and it allows the cookie
to be shared across sub-domains. Be sure not to add "www" */
document.cookie = cname + "=" + cvalue + "; " + expires + "; domain=.yourdomain.com";
}
/*Now we check our cookies on our secure server to find out if the user is
logged in or not. In my case, the First Name is stored as a cookie. */
var firstNameCookie = readCookie("the-secure-cookie-name");
//
if(!firstNameCookie){
/* If the cookie doesn't exist, then the person isn't logged in. Add
conditional logic here if you'd like (such as deleting any current
logged in cookies from the HTTP portion of the site) */
}
else {
/* otherwise, we have a successful login. By grabbing the cookie via
this javascript resting on the secure server, we haven't compromised our
security. However, if we set a cookie with javascript right now, it
won't be a secure cookie by default and we'll have access to it with
HTTP on the subdomain */
setCookie("HTTPfirstName", firstNameCookie, 1.5);
}
*/The clients first name is now accessible across subdomains in the cookie
entitled "HTTPfirstName" */
In this instance, the only thing we've leaked over to our HTTP server is the client's first name. However, if you would like even more security, you could set your server settings to only allow certain cookies (i.e. "firstNameCookie) to be accessed by an HTTP request, and that adds an extra layer of protection. You can learn how to do that here
Sure, this isn't the most ideal solution. In the future, I plan to implement SSL site-wide, but having a simple javascript function to replace it in the meantime is sure nice to have.
