Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Recent changes to the default settings.php automatically set session.cookie_domain. This patch does two things:
1) do not set session.cookie_domain if HTTP_HOST is an IP address
2) do not include port number when setting this value
Without this patch, valid cookies cannot be set for sites running on an alt port or sites being accessed via IP address (so folks like me cannot log in to their test servers :)
Comment | File | Size | Author |
---|---|---|---|
#8 | settings_cookie_domain_0.patch | 900 bytes | JohnAlbin |
#6 | settings_cookie_domain.patch | 791 bytes | JohnAlbin |
cookie_domain_1_0.patch | 1.31 KB | Harry Slaughter | |
Comments
Comment #1
Harry SlaughterWe will certainly want to optimize the regexes in this settings.php code.
for example, clouseau suggested using something like
/.\d{1,3}$/
instead of
/\d{1,3}.\d{1,4}.\d{1,3}.\d{1,3}/
It's obviously important that settings.php not contain any unnecessary overhead.
Comment #2
Harry Slaughterquick follow up, benchmarked the patch and there's no need to optimize anything.
Comment #3
drummLooks okay, but why only benchmark the existing function and not the new one?
Comment #4
Dries CreditAttribution: Dries commentedWhat exactly does this patch fix? What's wrong with using an IP address and/or port number?
Comment #5
Steven CreditAttribution: Steven commentedYou cannot set cookie domains to IPs as per the RFC. Same for port numbers. It must be a domain only.
Comment #6
JohnAlbinI noticed one additional problem with the existing cookie_domain code… it doesn’t strip the text “www.” from the front of the HTTP_HOST, it strips the regular expression “www.” from the front of the HTTP_HOST. (Right now, some guy at http://wwwisforsuckas.example.com is weeping because he can't login to his Drupal.)
The attached patch fixes all the 3 issues while incurring very little performance hit, since it simply expands the regex in the existing
preg_replace()
call.Comment #7
JohnAlbinModifying title to better explain issue.
Comment #8
JohnAlbinRe-rolled patch against latest 6.x.
Comment #9
Zen CreditAttribution: Zen commentedIsn't this being addressed in http://drupal.org/node/56357 as well?
-K
Comment #10
JohnAlbinYes. The patch in #56357 grew in scope to incapsulate a fix for this issue. But since they are separate issues and neither committed, I’m not comfortable with me setting this issue to duplicate until #56357 is in HEAD.
Comment #11
Dries CreditAttribution: Dries commentedLet's move this to: http://drupal.org/node/56357 ...