If you install your Drupal 5.1. in non-default port - you can't login. You can create the first user (admin) and login at that moment in but not again if you'll log out. If you try to login again you will be displayed only the same login form again.

Base URL with non-default port number seems not to work (e.g. www.example.com:802). If moving the installation to default 80 port and setting base URL without port-number - it works ok (www.example.com).

CommentFileSizeAuthor
#5 settings.php-cookiedomainport.patch556 bytesterotil
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tom friedhof’s picture

Priority: Critical » Normal

I 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.

terotil’s picture

I 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 $domain contains 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 $domain before setting session.cookie_domain fixed this for me.

@@ -142,6 +142,7 @@
  */
 if (isset($_SERVER['HTTP_HOST'])) {
   $domain = '.'. preg_replace('`^www.`', '', $_SERVER['HTTP_HOST']);
+  list($domain, $port) = explode(':', $domain, 2);
   // 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) {
adrinux’s picture

Status: Active » Closed (duplicate)

In 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

terotil’s picture

Status: Closed (duplicate) » Needs review

I 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

The terms request-host and request-URI refer to the values the client would send to the server as, respectively, the host (but not port) and abs_path portions of the absoluteURI (http_URL) of the HTTP request line. Note that request-host must be a FQHN.

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:

When it sends a request to an origin server, the user agent sends a Cookie request header to the origin server if it has cookies that are applicable to the request, based on

  • the request-host;

[...]

The following rules apply to choosing applicable cookie-values from among all the cookies the user agent has.

Domain Selection
The origin server's fully-qualified host name must domain-match the Domain attribute of the cookie.

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 $domain before setting cookie domain.

terotil’s picture

And the patch...

AmrMostafa’s picture

I 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.

AmrMostafa’s picture

I believe a solution should be implemented while fixing this: http://drupal.org/node/126340

AmrMostafa’s picture

JohnAlbin’s picture

Status: Needs review » Closed (duplicate)

See “session cookie not set when using IP address or alt port number

I’ll make sure the fix is back-ported to 5.x.