Closed (won't fix)
Project:
Hostmaster (Aegir)
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
6 Jun 2013 at 13:28 UTC
Updated:
14 Jun 2013 at 18:22 UTC
You can install and setup Aegir using an IP address as the site name (XX.XX.XX.XX) but you can't login.
The problem is the below bit of code in settings.php for the site:
if (isset($_SERVER['HTTP_HOST'])) {
$domain = '.'. preg_replace('`^www.`', '', $_SERVER['HTTP_HOST']);
// Per RFC 2109, cookie domains must contain at least one dot other than the
// first. For hosts such as 'localhost', we don't set a cookie domain.
if (count(explode('.', $domain)) > 2) {
@ini_set('session.cookie_domain', $domain);
}
}
This is correctable by commenting out the @ini_set line, however changing that line to the below would be a better fix:
if ((count(explode('.', $domain)) > 2) && (count(explode('.', $domain)) < 4)) {
I realize there is discussion that IP addresses shouldn't be used #1859478: Don't allow site domain names to be IP addresses, but they are good for test sites.
Comments
Comment #1
ken hawkins commentedComment #2
anarcat commentedwe need a patch here.
i am unclear as to why we need this special cookie anyways, any ideas?
the comment in the code seems to say this was in drupal core 5.2, but i can't find that anywhere...
Comment #3
omega8cc commentedThis is expected Drupal behaviour, not a bug, and it has nothing to do with Aegir.
It would be a bad idea to introduce "feature" not supported in the Drupal 7 core *by design*, so I tend to close this as won't fix. We should disallow using just IP for the site name to avoid confusion and to stay in sync with Drupal core behaviour.
See
function drupal_settings_initialize()in D7 --includes/bootstrap.incComment #4
anarcat commentedthis *is* a bug in aegir: the code inserted in D7 looks right:
ours doesn't:
Clearly we should catchup, no?
Comment #5
omega8cc commentedThe original issue is not our bug, because it blames Aegir for inability to login to the site, while it is Drupal core what causes this. So this is not a bug, at least not as originally submitted. We do should sync our logic for
$cookie_domain, because we use D5 style, while it has changed already in Drupal 6, but the real problem is that we allow to use IP address in the site name, which causes this confusion.Comment #6
anarcat commentedIn fact, I believe this code should simply be ripped out of the settings.php as it is *not* in D6 and D7's settings.php, as it is handled in bootstrap.inc.
In other words, this *is* a bug because we duplicate core logic in our settings.php, when we shouldn't do that at all.
Comment #7
anarcat commentedi removed the code that was Aegir's fault, this is now solely in core's hands. For the record, this was decided before 5.0 was released, and there's almost no explanation as to why IP addresses are forbidden, see #56357: Login issues with multiple sites in the same domain (session cookie collision). I believe this is a bug in core.