Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Hi,
AFAIK, this is not a reincarnation of the known "elusive login bug" (http://john.albin.net/drupal/critical-ellusive-login-bug).
In a nutshell:
- if a user visits the site, with an additional port number, for example: http://mysite.com:80/... then Drupal fails to see its the same user and opens a new session for it.
- it fails to see the existing cookie since it checks for a cookie name that is based on a md5 hash of the base_url which includes the port number.
longer story - use case for problem manifestation
- we integrate some 3rd party payment site on our site. This payment site , after any type of completion of the payment method (success/failure/doesn't-matter) sends the user back to our site, with some predefined URL. Unfortunately , this service adds (a nagging) port number to the URL. So, when user is redirected to our site, he's redirected to https:/www.my.site.com:443/ which leads to the mentioned severe problem - user is considered logged out + new session cookie is issued to him.
- to add an interesting bit, my browser (FF on Linux), when sent to http://....:80 or https://....:443 eliminates the port numbers from its interface, as those are the default port numbers for the http and https methods. this just adds to the confusion. BTW, further refresh on the page returns me to the site, logged in, as if nothing happened. Why? cause the refresh is based on the current browser URL - without the port number, so now the request is without the port number, and the session cookie name is set as originally, and cookie is found.
Suggested solution is attached in a patch. In essence, it includes a solution similar to that implemented on the stripping of the port number when setting the session cookie domain.
Boaz.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 618096-http-host-port.patch | 8.17 KB | damien tournoud |
| bootstrap_patched.inc-D6.patch | 702 bytes | boaz_r |
Comments
Comment #1
damien tournoud commentedThis affects Drupal 7 too, we have to fix this there, and then backport to all affected versions.
The real issue is that the automatic detection of
$base_urlfails to remove an explicit:80suffix from$_SERVER['HTTP_HOST']if it is passed by the client.Comment #2
damien tournoud commentedWhile writing tests for this, I also found that our handling of $base_secure_url and $base_insecure_url was also totally broken if an explicit port is used.
Let's try this one.
Comment #3
boaz_r commentednote that any port number in the "Host:" header should be removed (and not just port 80. We bumped it on 443). Its highly unlikely that two different drupals will run on the same domain on two different port numbers.
Also, I suggest a search through bootstrap.inc (and possibly other core file) for HTTP_HOST, SERVER_NAME, HOST (case sensitive to avoid numerous findings) and see if similar problems exists in the code.
Comment #4
damien tournoud commentedNo, it is not unlikely. And we should support that.
Comment #5
boaz_r commentedthen possibly the domain name of the session cookie needs to take into effect the port number, to avoid the session cookie sent to other drupal setups. Not a must - but cleaner and design should be the same across both cookie name and cookie domain configuration, IMHO.
I understand that multiple drupal installation might exist on the same domain on different ports, ok (a matter of decision). In that case it should be considered to clear also port 443. The question that should tell whether this should be made or not is if drupal installation should be reserved the option to use https for the same installation or not. If it is reserved, port 443 should be cleaned too. In my view, it is more logical that drupal installation should have https access reserved for it than enabling two different drupals on port 80 and port 443 in the same domain name.
Boaz.
Comment #6
flickerfly commentedboaz_r, The problem with the service redirecting in a silly and very abnormal way. Could it be solved with mod_rewrite rules somehow for your specific situation?
I agree that it is important to support multiple sites on the same domain with various port numbers. I suspect breaking this would break multi-site support. Currently, multi-site support allows the specification of a port number for a site through the convention
sites/8080.www.example.com/.Comment #7
boaz_r commentedflickerfly: right, the 3rd party service redirection is a pain in the @$$ since its both a minor issue to fix but at the same time not at my hands.
Moreover:
Thanks anyway!
Boaz.
Comment #8
flickerfly commentedSo it sounds like this is most appropriately a "won't fix" as the, mod_rewrite correction to an outside redirector solves the problem.
On the usage of ports:
I haven't recently, but have in the past run multiple websites on a single server using multiple ports. It is sometimes needed if multiple web-servers are needed. For example, Request Tracker can run as it's own web server or I've run web proxy services for libraries that require the use of a wide variety of ports. If you then have to put up a Drupal site to add documentation to go alongside these types of services then you must attach Apache to a non-80 port. If we're talking strictly an Apache environment, then it's no big deal, but once you step outside that, then things get complicated. Strange things can happen in an education environment.