Closed (duplicate)
Project:
Drupal core
Version:
5.1
Component:
base system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
9 Mar 2007 at 20:24 UTC
Updated:
23 Apr 2007 at 23:25 UTC
Jump to comment: Most recent file
Comments
Comment #1
tom friedhof commentedI can't reproduce this bug. This is a critical bug if it easy to reproduce, but I can not reproduce this issue in any of my enviroments, changing status to normal. You may have another issue going on possibly in your apache or php configuration.
Comment #2
terotil commentedI can reproduce this.
I have clean install of drupal 5.1 on Apache/2.0.54 PHP/4.4.0 listening ports 80 and 8080
The issue is AFAIK that default/settings.php does
ini_set('session.cookie_domain', $domain);where$domaincontains also port number iff URL had it. I'm not really sure whether this is a bug in my browser (should it include port number in http header 'Host'?), apache/php (what they should do with host-header including port number?) or drupal.Simply droping port number from
$domainbefore settingsession.cookie_domainfixed this for me.Comment #3
adrinux commentedIn principle Terotil is right, session cookie the problem and the answer, some more details though:
settings.php in HEAD, and 5 has been updated to deal with this, and the fix will be in 5.2, but you still need to do some manual config. See this thread for the patch:
http://drupal.org/node/117917
Comment #13 has the most recent version of the patch, check my comment #28 to see how I fixed this problem after applying the patch.
Marking this a duplicate of http://drupal.org/node/117917 since there are so many dupes for this but that's where the solution lies
Comment #4
terotil commentedI do not think this is a dupe. The mentioned patch does not change the fact that port number goes to cookie domain and manually fixing the cookie domain is not really a solution, because the problem is that cookie domain code in default/settings.php produces broken cookie in case
$_SERVER['HTTP_HOST']contains port number.AFAIK port number should never be included in cookie domain. Currently it is if
$_SERVER['HTTP_HOST']contains it. Browsers end up not sending the cookie back to server when domain in cookie (having port number) does not match the host the request is sent to.Cookie RFC http://www.ietf.org/rfc/rfc2109.txt?number=2109 says
So, in this RFC request-host is FQHN, and without port. "4.3 User Agent Role" > "4.3.4 Sending Cookies to the Origin Server" has the beef:
This is to say that user agents (when deciding to send or not to send a cookie) do domain-matching of servers FQHN (request-host, no port number) against cookies domain attribute. If cookies domain contains port number, no request-host will ever match it, because request-host never (per RFC 2109) contains port number.
Straightforward fix (patch on #2) is to remove the port from
$domainbefore setting cookie domain.Comment #5
terotil commentedAnd the patch...
Comment #6
AmrMostafa commentedI can easily reproduce this myself. The patch solves this problem, and I can clearly see that the cookie is always rejected by the browser without this patch.
However, what if you have foo.example.com and foo.example.com:1234 ? i.e. two sites on same domain, but different ports.
Comment #7
AmrMostafa commentedI believe a solution should be implemented while fixing this: http://drupal.org/node/126340
Comment #8
AmrMostafa commentedErm, http://drupal.org/node/56357
Comment #9
johnalbinSee “session cookie not set when using IP address or alt port number”
I’ll make sure the fix is back-ported to 5.x.