I have installed drupal and have had it working flawlessly over my local network. Recently I decided to show it to a friend and had him access it via domain name and had a very strange issue. The login page would constantly cycle so I check all over the net and saw various fixes for previous drupal version, some of which I tried, none of which have worked. I was about to give up even though I knew the problem was with cookies. I decided to try accessing the page through Firefox and checking the cookies there. That when I figured out the most important part of the issue, if I access the webpage through any address except fort he internal ip address of the server Drupal would not write ANY cookies!

Drupal itself worked flawlessly. In the logs I saw the session get created. It seemed the only issue is that if anyone tried to access the page via FQDN or even my external ip address the cookie would not be created!

Is there a fix to this?

Comments

Haggle’s picture

No ideas anyone? Shouldn't this be considered a serious bug if people can't access your website outside the network the server is on?

All my components are up to date...

Windows 2003
IIS 6
PHP 5.2.1
MySQL 5.0.27
Drupal 5.1

Haggle’s picture

I have recently switched over to apache from IIS 6.0 to see if that would help. I am still not getting a cookie from the external address. Heres a example of whats going on...

I got to the internal address http://192.168.15.50 and I can see a cookie made for that same address with my PHPSESSID. Now I try to login from my external domain http://example.com:8080/ and I get nothing. No cookies for the external or internal ip are made when I access the site from the external address (this includes my external ip address as opposed to the domain name).

Any help/ideas/feedback/links would be great

Haggle’s picture

More info on the problem...

Accessing web page through private (internal 192.*.*.* address) creates a cookie in Firefox like so... site = 192.*.*.* [this is shown as a folder which then opens to the cookie] PHPSESSID [under cookie name].

When accessing the site from example.com
Firefox does NOT make a folder for it
Firefox does NOT make a cookie for it
There is no anonymous cookie or any sort of cookie made in Firefox or IE
Drupal does NOT use the cookie made by the internal address (the 192.*.*.* cookie)

I have attempted to fix the matter myself with some basic knowledge of what I'm doing. I have tried nearly every fix offered for the persistent login bugs although none have had my specifics. I have also attempted changing the base_url in setting.php to match my .com address which did not work in creating a cookie.

Once again this only happens when accessing the site from a domain name or external network IP address.

I get a cookie and can log in with no error if I access the page through the server's private network address.

Haggle’s picture

Just thought I should post a fix to this incase anyone finds this thread. I got the info from Crell in irc (thank Crell!)

you will need to add some code to your settings.php file....

right below

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);
  }
}

paste this code

ini_set('session.cookie_domain', '.example.com');

change example.com to your domain name. If you are using a DDNS service it would look like this example.no-ip.org

Hope this helps people in the future.

osopolar’s picture

The symptoms of my problem where quite similar. Safari and the Internet Explorer didn't accept the cookies send by my local drupal site.

It was working for drupal.org but not for my local site. I compared the HTTP-Headers from my local site and that from drupal.org - they where pretty much the same.

But somehow Safari and the IE where accepting the cookies from drupal.org but not my local ones. So it thought there is something wrong with the cookie. I changed the domain name of my local site (I am using Apaches virtual hosts) and this solved the problem.
(I named my local site like mysite.local ... because if I'm naming it like the real domain I think I cold not access the real domain meanwhile I am developing. Now I changed for somewhat like: www.mylocalsite.org and both, Safari and the IE are accepting the cookie).

I hope that will help for those whose problems couldn't be solved by all the solutions you can find in this forum.

Chau:)

deepakapte06’s picture

None of the solutions given above seem to work !!

I have published my drupal site to make it accessble externally.

But the login page gets reloaded.

I am using an IP address with a port number.
example:
http://111.111.111.11:9090/drupal-5.1
i have already tried changing the base url.
and tried configuring the .htaccess file to accept ip address.

# If you want the site to be accessed only WITHOUT the www. prefix, adapt
# and uncomment the following:
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule .* http://111.111.111.11:9090/drupal-5.1[L,R=301]

Any ideas what might work?.

the site is perfectly accessible over LAN . ie when i give my local ip address!

Please help! SOS!
Thanks in advance.

deepakapte06’s picture

Problem Solved.
Tried every solution possible posted on forum (the ones i could find in the drupal jungle!).

here's how i solved. the above problem.

step 1 :enter the base url
$base_url = 'http://200.200.200.20:9090/drupal-5.1'; // NO trailing slash!
step 2 : (weird but true). comment the cookie domain!!
/**
* We try to set the correct cookie domain. If you are experiencing problems
* try commenting out the code below or specifying the cookie domain by hand.
*//*
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);
echo $domain;
}
}*/ // line of code i had placed earlier also to be commented!
//ini_set('session.cookie_domain', '.200.200.200.20:9090');
/**

Cookie get created !! the site now is accessible from the external link.!

i have not tested this stuff extensively (but works both on IE and firefox). but at least now i can access and perform all the tasks .

Cheers!
Deepak

Lowbacca’s picture

Again, I feel like I've been stalking these boards to find a fix that works for the above problem.

I understand locating the "settings.php" file but where does one copy paste the above fix within the code that doesn't make the index page go white?

Also, I have done the "request new password" to try to reset it only to have it cycle as well with a blank content screen and the number "2" on the page, this left me with no luck getting back in. I have cleaned the cache, deleted cookies, placed code within code and all the other possible fixes. I have checked the phpMyAdmin sessions and believe that when I read through the "cache" and possibly figured out the time stamp, it does look like I am logging in. As you can see from the following link http://drupal.org/node/144917 I believe I've tried just about all I can figure out on my own.

One thing I did do tonight that had a minor success was reload Drupal 4-7-3 onto the site and at least when I tired to login, it showed it could recognize my user name but not the password since I did request a new one earlier in the evening and couldn't change it then. A minor victory but to me shows that it didn't cycle back to a login screen.

I hate hand holding, I like to figure things out on my own but I've been "locked" out my of my site since this has started and I need to get some updates done this week. I have been able to "limp" through doing some minor things by going into phpMyAdmin/boxes and making the changes there but the changes will only show-up in a subfolder and not the main directory, I'm using the php bounce code to the subfolder so the changes show.

I'm presently running Drupal 4-7-6 on a Yahoo small business site running php 4.3.11. The browsers that I use are Firefox 2.0.0.3 and Safari 2.0.4 (419.3). Also, I have tried this whole thing on a PC running XP and the latest version of Firefox and IE - still not able to login in. The only add-on module I put into the site was "poormanscrons."

Lastly, I have another site that I loaded Drupal 4-7-3 into a subfolder and it so far work it works fine.

Any and all help would be greatly appreciated - Thank You!!

cgrantham’s picture

For us new users, can you please provide the full path to files? I have no idea where "settings.php" is. I have found about 3 of them, too. Thanks for any clear direction you can provide :)

Also, in the setting.php files I've seen, the following code:

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);
  }
}

does not exist.

coreyp_1’s picture

The reason that the file location for settings.php is usually not given is because it can be in different locations, depending on how your installation is set up.

That being said, it is generally located under "sites/all".

- Corey

joric’s picture

As deepakapte06 said above, the problem is in RFC 2109. Oddly enough, it occurs only if you use firefox.

You have to comment out lines I marked with "-":

bootstrap.inc:

// Per RFC 2109, cookie domains must contain at least one dot other than the
// first. For hosts such as 'localhost' or IP Addresses we don't set a cookie domain.
-if (count(explode('.', $cookie_domain)) > 2 && !is_numeric(str_replace('.', '', $cookie_domain))) {
- ini_set('session.cookie_domain', $cookie_domain);
-}
-session_name('SESS'. md5($session_name));

For a strange reason it fixes the problem.