| Project: | Bakery Single Sign-On System |
| Version: | 7.x-2.0-alpha3 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
I'd like to namespace the shared cookies in a standard way (based on the cookie domain), to prevent getting cookies that can't be deleted on a sub-sub domain.
For example, we have environments like *.example.com, *.a.dev.example.com, *.demo.example.com, *.stage.example.com. Cookies from *.example.com have been encrypted with a different key, so at least they are invalid in these environments, but the subsites can't actually overwrite/delete the cookie from *.example.com, so if you have a cookie from there, you can't login.
I could be wrong on this, here's a stackoverflow q with answers seeming to agree though - http://stackoverflow.com/questions/3923285/how-to-remove-main-domain-coo....
The only solution I could come up with is to namespace the cookies with the cookie domain, e.g. EXAMPLE_COM_CHOCOLATECHIP.
Thoughts?
Comments
#1
My other thought is to restructure bakery to not care if a cookie from another domain is set, overwrite it if it needs one, ignore it if it doesn't.
In testing though, I can't seem to make that work, the cookie from the parent domain appears to win.
#2
It seems parent domain cookies override sub domain cookies no matter what I do, so I went with namespace as the original proposal. Basically:
$type . md5($cookie_domain);Resulting in:
D6 patch, D7 to follow.
#3
Sorry, included another patch. Still rolling the 7.x patch.
#4
7.x patch.
These patches also have add some DRY-ness to the SSL cookie patch.
#5
I'm changing this to a bug, I'm sure it's not major, but it's pretty frustrating for our use case. Basically we can only have one Bakery environment on our domain without it (no demo, no dev-stage, etc).
#6
I understand it's pretty frustrating, but it's a feature request to handle your specific use case. I haven't reviewed the patch yet, will think on this more. I understand you want to support your work flow but I hesitate in all cases of increasing the complexity of the code base.
#7
I hear you, though I really think the complexity is minimal, considering the SSL patch that is already in. Here is the cookie name function from the patch:
/**<?php
/**
* Generate the name for a bakery cookie, this prevents domain
* mismatch on subdomains that are not part of a parent domains bakery config.
*
* @param string $type
* CHOCOLATECHIP or OATMEAL, default CHOCOLATECHIP
* @return string
* The namespaced cookie name for this environment.
*/
function _bakery_cookie_name($type = 'CHOCOLATECHIP') {
// Use different names for HTTPS and HTTP to prevent a cookie collision.
if (ini_get('session.cookie_secure')) {
$type .= 'SSL';
}
// Namespace the cookie by the cookie domain. Use md5 to avoid using any
// reserved cookie terms (all of which contain non-hex characters):
// "expires", "domain", "path", and "secure".
$name = $type . md5(variable_get('bakery_domain', ''));
return $name;
}
?>
#8
re-rolled against alpha3 tag, and also adding some missing cookie_secure's.