after upgrade from 6.16 to 6.17, I can't login anymore

By kccheng on 3 Jun 2010 at 11:39 UTC

Hi,

I follow the procedure in UPGRADE.txt to upgrade my site from 6.16
to 6.17 (except that I did not turn my site off-line, since it's the internal site and
currently, I'm the only one use it).

The update procedure work smoothly but after upgrade, I can't login to
my site anymore !!

I check the database directly and find the user/password still there.
The the password is encrypted by MD5 correctly (I use 'md5sum' to check the
encrypted password manually).

Any suggestion ? Thanks.

Regards
KC

Comments

.

cog.rusty commented 3 June 2010 at 12:28

What happens when you try to login? Also, what happens when you enter a wrong username/password?

Did you use the same settings.php file you already had? Did you have any $base_url and/or any $cookie_domain setting in it? Or were they commented out with a #?

Find your site's cookies in your browser, read then, and see what cookie domain they contain. Is it ".example.com"? Delete those cookies and then try to login again to see if it makes any difference.

Hi, When I login, nothing

kccheng commented 3 June 2010 at 12:41

Hi,

When I login, nothing happen ...
I traced user.module, and found I were treated as anonymous user ...

I copied my settings.php from 6.16 to 6.17.

The $base_url is commented out, and I set my $cookie_domain to my domain name.

Regards,
KC

Thanks cog.rusty's hint

kccheng commented 3 June 2010 at 12:47

Thanks cog.rusty's hint ...
After clear all cookie, I can login to 6.17 now.

I think it will be great if UPGRADE.txt can mention this.

Best Regards,
KC

.

cog.rusty commented 3 June 2010 at 13:15

It might be the $cookie_domain which you had set.

Until now, if you had $cookie_domain set to either "example.com" or "www.example.com", drupal was automatically setting PHP's session.cookie_domain='.example.com', as is normally correct.

I think that changed now and Drupal uses whatever you tell it, to make it possible for people to set it "incorrectly", if that was what they need (for example if they want different sites at example.com and www.example.com). So, if you have set explicitly $cookie_domain="www.example.com", then that is what will be used, which is different from before.

So, should I update all my

cledwyn commented 4 June 2010 at 19:04

So, should I update all my $cookie_domain to '.example.com'? what is the recommended formatting?

.

cog.rusty commented 8 June 2010 at 08:37

The general rule is to leave that line disabled, except if you have a problem to solve, or if you want to achieve something by changing it. There is an RFC 2965 specification (I think) about cookie domains, which Drupal follows. In brief:

http://example.com
- the cookie domain is automatically set to .example.com

http://www.example.com
- the cookie domain is automatically set to .example.com
It is the same as the first one, so that a site can use the same cookie and keep the users logged in, either they use "www" or not.

In both cases, you could have set $cookie_domain="example.com"; in settings.php to achieve the .example.com cookie domain, but it is not necessary.

Now the subdomains:

http://subdomain.example.com
- the cookie domain is automatically set to .subdomain.example.com
This is different: now there can't be shared sessions/shared login between this site and http://example.com, because the cookie domains are different.

But this can change: By setting $cookie_domain = "example.com"; in this sub-site's settings.php file, you make it change the cookie domain to .example.com, same as the main site, and now it is possible to achieve shared sessions/shared login with this site as well, by using some shared Drupal database tables.

If you have set explicitly $cookie_domain = "www.example.com"; (which since Drupal 6.17 means that cookie domain = .www.example.com), you need to make sure that your site URLs will always use "www", or else the user will be kicked out. And If you change it back or remove it, to avoid this problem, users may need to clear their browser cookies again.

I think this wraps it up. Leaving that setting disabled if you don't have a reason to change it is the best practice.

--------- Edit: Correction

Since Drupal 6.17, when you specify a $cookie_domain the front dot is not added automatically any more, and if you need it you must add it.

$cookie_domain = '.example.com';

As alway, the safest choice is not to specify a $cookie_domain, unless you have a reason to specify it.

# $cookie_domain = '.example.com';

Excellent explanation. Thank

cledwyn commented 9 June 2010 at 02:04

Excellent explanation. Thank you.

This helped me

DanilaD commented 16 June 2010 at 04:21

Thank you, cog.rusty.

This helped me - before the upgrade I had $cookie_domain = 'www.example.com', and I could not login no matter which browser I tried. Changing it to $cookie_domain = '.example.com' helped. I use a single site installation.

Regards,
Danila

Thank you!

Drupalized commented 5 July 2010 at 09:47

Thank you!

Thanks- it worked

twood commented 24 August 2010 at 16:29

Thanks so much- never even knew the cookie domain was there...

My domain is

ACall commented 5 June 2010 at 04:05

My domain is (www.)iceboatdynamics.com

On the host it runs out of the subfolder /drupal1
I had various settings in the .htaccess file to properly redirect from both www.iceboatdynamics.com and iceboatdynamics.com to the subfolder /drupal1

In 6.16 in my settings.php was as follows:
$base_url = 'http://www.iceboatdynamics.com';
$cookie_domain = 'iceboatdynamics.com';

With the above settings I could access the admin portion of the site with only one login when starting with www.iceboatdynamics.com or from iceboatdynamics.com.

When I updated to 6.17, it took two logins when entering via iceboatdynamics.com. Entering via www.iceboatdynamics.com only took one login.

I cleared all cookies and it make no difference.

After reading the earlier part of this thread, I decided to comment out the $cookie_domain line!

Now everything is good. Only one login needed when entering by either method.

.

cog.rusty commented 5 June 2010 at 13:41

Adding this just to make a correction to what I wrote in the previous one.

Since D6.17, the right way to set $cookie_domain is:

$cookie_domain = ".example.com";

The required front dot is not added automatically any more. That should also work in your case, but there is no need. (Except if you need to use this in a subdomain site).

I uncommented the line and

ACall commented 5 June 2010 at 18:41

I uncommented the line and put it back in as:
$cookie_domain = ".iceboatdynamics.com";

It works correctly for both login methods.

Thanks...

(subscribing)

bryrock commented 8 July 2010 at 21:57

(subscribing)

Live Better Eclectically!
-- Bryrock

Or is it in $base_url?

tryitonce commented 7 June 2010 at 10:37

Same problem here - I upgrade - logged out of the site and tried to get back in in Firefox.

No go.

Before finding this I closed Firefox and uncommented and changed the line

*/ $base_url = 'http://www.example.com'; // NO trailing slash!.

to include my-site-name -

$base_url = 'http://www.my-site-name.com'; // NO trailing slash!.

I guess this might not be necessary - or?

Probably closing the browser and starting again solved the problem.

_

tryitonce commented 8 June 2010 at 08:12

...... it is in the cookies setting.

I had activated that some time ago in respect of some SEO advice.

So, just closing and restarting the browser probably did the trick.

oy! changes like this need to be implemented better!

decibel.places commented 7 June 2010 at 17:15

I upgraded to 6.17, had this problem, checked my cookie domain, then rolled back to 6.16 THEN I found this thread about the change to cookie domain...

When such a fundamental change is made, and in a file like settings.php that we need to manually edit to make the darn thing thing work, the change needs to be implemented better.

Like checking if the cookie domain has the leading period, if not displaying an alert... many contrib modules will do this when a fundatmental change needs to be made, why not core?

~are you netsperienced?
♥ follow me @decibelplaces ∞

.

cog.rusty commented 7 June 2010 at 19:18

A note was added to the release announcement, but I agree that they missed the consequences. It was a somehow hasty backport of a Drupal 7 change in http://drupal.org/node/458704 and the comment in settings.php is still wrong.

I would bet that this is not the last change we will see in that area.

backport of a Drupal 7 change

decibel.places commented 8 June 2010 at 16:28

I suspected it was a backport - but better to leave the usual D6 config and apply the change to a major upgrade like D7

once you know about it, no big deal, but not everybody reads release notes (at their own peril).

when I upgrade core I do not overwrite the /sites/ directory or .htaccess

~are you netsperienced?
♥ follow me @decibelplaces ∞

After correcting

sotiris commented 8 June 2010 at 18:17

After correcting $cookie_domain = ".example.com"; it solved the login problem, but also there is a problem with autocomplete.js and ajax, both they are not working anymore after upgrading from 6.16 -> 6.17. Does anyone has any solution for this, i think i must a create a new issue for these two.

update: http://drupal.org/node/821954

A mayor change!! This really

rodrigoderteano commented 23 June 2010 at 16:28

A mayor change!! This really got me wondering why i couldn't log in as admin any more and one of my customers had a presentation which went bad. This really should not have been done! And if it was necessary, then communicate it like what it is, a mayor change in the functionality of drupal!!!

delete your stored cookies!

skaught

English

commented 15 June 2010 at 16:15

delete all you browser cookies [from test domain, localhost, 192.168.X.X, project.local, project.com--whatever you've set up], this worked for me.

tip:

i always use:

$cookie_domain = $_SERVER['SERVER_NAME'];

in my settings for local dev to live server. make it dynamic (-:

also [for base path]

$base_url = 'http://'.$_SERVER['SERVER_NAME'];

.

cog.rusty commented 15 June 2010 at 16:40

In some use cases (Drupal multisites) it is simpler to remove those settings and let Drupal use the $_SERVER['HTTP_HOST'] which the client requested to get there.

The value of $_SERVER['SERVER_NAME'] can be constant (a vhost's ServerName) or varying (the HTTP Host header), depending on whether the UseCanonicalName setting is On or Off in Apache's configuration.

tested and works for D 6.17

decibel.places commented 15 June 2010 at 20:44

@skaught1

I like this dynamic setting for $cookie_domain - have you considered adding this technique to the documentation book pages somewhere?

~are you netsperienced?
♥ follow me @decibelplaces ∞

some modules require $cookie_domain

decibel.places commented 15 June 2010 at 20:52

such as CKEditor with CKFinder requires $cookie_domain to be set correctly...

~are you netsperienced?
♥ follow me @decibelplaces ∞

Firefox and Safari are different

cvdenzen commented 17 June 2010 at 22:35

On Firefox I could not login, but in Safari I could login. Is there an explanation for this behaviour?

btw: I am running a multisite Drupal, with Drupal installed in a subdirectory public_html/drupal.
One of the sites (vandenzen.nl) is running from the root. Maybe it works just by accident. I put this line in my .htaccess (in public_html, my root):
Redirect 301 /index.html http://drupal2.vandenzen.nl/

Another site of my multisite setup is arjan.vandenzen.nl, which is redirected to the drupal subdirectory. This site works just fine, no login problems, not in FireFox and not in Safari.

I changed my settings.php for my root domain vandenzen.nl (put a dot in front of the cookie domain). Problem resolved.
For arjan.vandenzen.nl the cookie_domain was not set (commented out).

.

cog.rusty commented 18 June 2010 at 01:22

In Drupal 6.17,
- with $cookie_domain commented out, Drupal computes and sets a correct cookie domain.
- with $cookie_domain=".example.com", Drupal sets the cookie domain to exactly what you asked, which is fine in this case.
- with $cookie_domain = "example.com", Drupal 6.17 doesn't set the cookie domain at all. So, according to RFC2109 4.3.1 the browser should use the request-host without a dot instead, and then according to RFC2109 4.3.2 the browser should reject that cookie. The difference between browsers is how closely they follow the standard.

I haven't had $cookie_domain

crosputni commented 22 June 2010 at 15:43

I haven't had $cookie_domain set but I am having the same issues with logging in. I've tried using different browsers, logging in as different users, triple checking my .htaccess and settings.php files, clearing my cookies and cache, I even rebooted my computer - nothing I do allows me to log in.

Since I didn't have $cookie_domain set, is there any other reason why I wouldn't be able to log in after upgrading to 6.17? I would really rather not have to revert back to 6.16 but I will if necessary.

Thanks in advance for any help.

Ok, something happened with

crosputni commented 22 June 2010 at 15:57

Ok, something happened with my user ID and password during the update. I was able to reset it using your post here. http://drupal.org/node/160354#comment-253357

Thank you very much for all of your valuable input in the forums!

.

cog.rusty commented 22 June 2010 at 15:57

Questions:
- Are you trying to achieve any kind of shared login, or is each site on its own?
- What was the purpose of the Redirect 301 that you mentioned?

Also visit each site in turn and try to login after clearing you browser cookies, and read each cookie created and check the "Domain" that it contains. What are the cookie domains of the sites?

I'm not sure what the issue

crosputni commented 22 June 2010 at 17:17

I'm not sure what the issue is. After updating to 6.17, my login didn't work. I had to go into the database and manually reset my password. Once I did that, I was able to access everything as usual, but when I enabled all of the modules, I got WSOD on every page, including update.php. I'm pretty sure it's one of the modules I'm using because the site worked fine when all of the modules were disabled.

I haven't actually set up the second website yet. I will be setting up a second website to act as a multisite (with shared user information) shortly. Since I updated to 6.17 from 6.16 and enabled the modules, I get WSOD. I don't have time to go through each module right now to see which is causing the issue so I'm just going to have to roll back to 6.16.

Help!

crosputni commented 22 June 2010 at 18:31

Ok.. now I'm beyond frustrated.

I reverted back to 6.16 and used my database backup from before the update - no luck, WSOD on modules page and most other admin pages. I cleared cookies and cache, closed my browser, reopened, and still WSOD on most admin pages. My memory limit is set to 100M - I even tried setting it to 200M which should be more than enough so I don't think that's the issue. I manually disabled all modules via mysql. I don't even know what else to do at this point.

Also, when I'm logged in under www.my-site.com, it shows me as an anonymous user on my-site.com (without the www.). I don't have $cookie_domain or $base_url set - they're both commented out.

Seems that the issues are just popping up all over the place. Help!

.

cog.rusty commented 22 June 2010 at 20:13

About the PHP memory_limit, check what the admin/reports/status page inside Drupal says. But even if you have set a high PHP memory limit, you may be hitting another limit set by Apache. To be sure, run an actual memory test to see how far it can go. Upload and run this script and see at what point it crashes with an "out of memory" error.

// memcheck.php

ini_set('display_errors', 'On');
$new_mem_limit = '256M';
$old_mem_limit = ini_set('memory_limit', $new_mem_limit);
print 'Memory limit changed from '. $old_mem_limit .' to '. $new_mem_limit .'<br />';

$step = 1;
while(TRUE) {
  $chunk = str_repeat('0123456789', 1024*1024*$step++);
  print 'Memory usage: '. round(memory_get_usage()/(1024*1024)) . 'M<br />';
  unset($chunk);
}

Also try to remember if you had some previous setting in your .htaccess file which the new upload has overwritten. Maybe there was a line to enable PHP5? Does the admin/reports/status page report the correct PHP version?

Are you domain names real or local? Your cookie domains should be fine, but try to set them all to ".example.com" anyway and see if anything changes.

Thank you so much for your

crosputni commented 22 June 2010 at 21:38

Thank you so much for your help thus far. Here's what I've got for you:

The status report shows that the PHP memory limit is set to 200M which is correct according to my settings.php and php.ini files.

When I ran the memcheck from the file above, here's what it gave me

Memory limit changed from 64M to 256M
Memory usage: 10M
Memory usage: 20M
Memory usage: 30M
Memory usage: 40M
Memory usage: 50M
Memory usage: 60M
Memory usage: 70M
Memory usage: 80M
Memory usage: 90M
Memory usage: 100M
Memory usage: 110M
Memory usage: 120M
Memory usage: 130M
Memory usage: 140M
Memory usage: 150M
Memory usage: 160M
Memory usage: 170M

Fatal error: Out of memory (allocated 262144) (tried to allocate 188743681 bytes) in /home/content/v/v/u/vvusa/html/memcheck.php on line 11

To me, that says it's running out for anything over 170M, which I would assume is ample memory.

For the .htaccess file, I maintained the same settings that Drupal comes with. The only exceptions are that I changed the query string and added a RewriteCond for a folder that I need Drupal to ignore.

My server is set up on GoDaddy to use PHP 5. According to the Status Report, it is using PHP 5.2.8.

My domains are real. The site was live but took I took it offline for the update to 6.17 this morning and it's been in maintenance mode ever since.

I don't currently have $cookie_domains set to anything in settings.php - it's commented out. Would uncommenting that and changing it to .my-domain.com possibly solve the issue with logging in?

I should also note that I had to turn off the Update module and that allowed me to access some of the admin pages, but the majority are still showing the WSOD. The few that do load take a very long time or come up with an "Internal Server Error" message.

.

cog.rusty commented 23 June 2010 at 02:29

Your memory limit seems fine.

For the "www" login problem, settings $cookie_domain = ".example.com"; shouldn't make any difference, but it doesn't hurt to try it. Do you have any kind of "remember me" module installed? If you have, try to disable it.

For the WSOD and "Internal Server Error" problems I have no idea what it could be. In case it is a timeout error, try max_execution_time = 60 in php.ini.

It could help to find Apache's error log and access log files and see what they say at the time the problem happens. See if the logs say anything about mod_security.

-------- Edit:

Something that I remembered. Make sure that your site which has the login problems has a user with uid=0 (the anonymous user). If you find that user 0 disappears after loading your database from backup, next time remember to add to the top of the database dump the line NO_AUTO_VALUE_ON_ZERO

One issue down, one to go.

crosputni commented 23 June 2010 at 14:37

I did have the Remember Me module installed, but disabling and uninstalling didn't change the "www" login problem. Thankfully, I was able to fix that by setting $cookie_domain = ".example.com". One issue down, one to go.

I set the following in php.ini max_execution_time = 60 (previously, it was set at 30) which seems to have lowered the number of WSOD and Internal Server Errors I'm getting but for some reason, they still show up every 20 minutes or so. I checked the logs, and every time I get an Internal Server Error, the log records the following:

[Wed Jun 23 07:22:50 2010] [error] [client **.***.***.***] (104)Connection reset by peer: FastCGI: comm with server "/home/content/*/*/*/****/html-x-httpd-php5" aborted: read failed

[Wed Jun 23 07:22:50 2010] [error] [client **.***.***.***] FastCGI: incomplete headers (0 bytes) received from server "/home/content/*/*/*/****/html-x-httpd-php5"

The ** represent my IP and the path to my server

Nothing about mod_security, and no errors are reported when I get WSOD. I've been searching the forums and book pages for this issue and so far, none of their remedies seem to do anything. By reading the above errors, I would assume that there is an issue with my headers. Is my assumption correct? Do you have any idea what could be causing that or what I can do to fix it?

These errors were not showing in the logs before updating to 6.17 and then rolling back to 6.16.

.

cog.rusty commented 23 June 2010 at 15:13

The first error is more important. The second one may be a result of the first.

Reports of that error all over the web indicate that it is either server configuration or a bug. Apache's fastcgi module may be misconfigured or too old. If it is not your own server, probably only your host can fix it.

cog.rusty, thank you VERY

crosputni commented 23 June 2010 at 21:18

cog.rusty, thank you VERY much for all of your help with this! It's nice to have some help when I've hit the rip-my-hair-out stage of frustration.

I spoke with my host about the errors that the log is showing. After 4 hours and several department transfers, they informed me that they are doing an update on my server at the moment. Apparently the PHP errors should be fixed by the end of the week. Unfortunately now I've run into a new error in my log: mod_rewrite: maximum number of internal redirects reached. I'm sure it's related to something I changed while trying to fix the WSOD.

I also discovered that the query string that I changed was causing an issue on my home page. But only on the home page. It was a "Notice: Undefined Index" issue. For the time being, I switched the query string back to "q" and it's working properly. Now I've hit an issue with Webform, but that's a conversation that belongs in another issue cue.

.

cog.rusty commented 23 June 2010 at 22:49

The "q=" query string can't change, it is essential. Even with clean URLs it is always carried in $_SERVER['QUERY_STRING'] and examined explicitly all the time with $_GET['q'], for example in the arg() function.

About the rewrite which caused the redir loop, are you sure that you need it at all? Drupal seems to "take over" a subdirectory only if it was inaccessible anyway. Usually it is enough to add to the subdirectory, for example, a DirectoryIndex index.html to run a static site, or an Options +Indexes to let people browse it, and Drupal won't interfere.

_

tryitonce commented 23 June 2010 at 22:53

Change your host - don't know what contract your are own - I never had such problems with http://www.5quidhost.co.uk for enduser accounts and http://www.tentahost.co.uk for resellers account. They respond within the hour - mostly at resonable office times - i have never been transfered to another department - all just by email and all sorted out very well - sometimes with a bit of dialog to get the help I needed to solve problems at my end.
Great service so far - highly recommended and that from someone very cautious about recommending others as you never know.....

Query string and GoDaddy only FastCGI errors.

crosputni commented 28 June 2010 at 17:44

The query string was modified based on this book page: http://drupal.org/node/193069 which I have done for several other Drupal sites with no issue. Although I should probably note that the other sites were not hosted with GoDaddy and this one is.

I'm pretty sure that the GoDaddy shared hosting is the issue. I took a copy of the entire site and set it up on one of my personal host accounts with BlueHost and have yet to get the FastCGI errors, or any errors at all. Unfortunately, the IT guy here isn't the brightest bulb in the box and has convinced the boss that it would be detrimental to our company if we switch hosts. After lots of run around from GoDaddy last week they told me they were fixing the error. When I called back this week (they said it would be fixed by last Friday), they said they had no record of my previous call. Ugh. So I guess I just have to deal with the 505 errors, WSOD, and FastCGI issues until I can convince my boss to let me switch everything over.

Thank you both for your assistance with this issue. I really appreciate it.

_

tryitonce commented 28 June 2010 at 21:17

Well, write down the hours you spent and the response times from GoDaddy. Workout the time it cost your business in down time and bill your boss or IT guy - proforma.

Set-up another site on any good host - the one I used are just great and it never took long to get things sorted - even if it was my fault.
Then demonstrate to your boss what he could have saved. I actually took all my domains out of GoDaddy - I get enough stupid sexism into my Spam box - I don't need them with their strange way of trying to slip you unnecessary add-ons to your account before you get to the check-out plus the currency changing tricks between US$ and Euro ..... - it is just too much - I prefer straight services that will cost the same or less actually when you add it all up and over time ...... moan, moan, moan .....

.

crosputni commented 29 June 2010 at 15:05

Trust me, I know how crappy GoDaddy is. When I first got into this business, I worked for their customer service department. Horrible. They basically tell you to focus more on selling products than on helping the customers who call in for support.

Thanks for the excellent idea. I'll definitely track the time I wasted and show my boss how much money he could have saved. Hopefully I'll be moving everything shortly.

cookie_domain changes worked

citronica commented 20 June 2010 at 01:17

Thanks cog.rusty! My login was broken the same way others described, so I took your advice I commented out cookie_domain. I didn't need it anymore anyway, since the only reason it was set was because the site used to use FCKeditor.

Thanks again rusty.cog!

markosaurus commented 24 June 2010 at 10:09

As usual you've saved the day!

This had me tearing my hair out after upgrading from 6.16 to 6.17. I could not log in, I check the DB and my password was the same, so I knew that was right (Is it wrong that I know my hashed password by heart?)

Went into settings.php after seeing your advice and saw that $cookie_domain was set to http://www.domain.com. Changed it to domain.com et voila!

If I can find a big fat "Thank" button I'll certainly press it.

Mark

nice solution by skaught1 maybe lost in this thread

decibel.places commented 25 June 2010 at 04:19

I want to repeat and highlight a very nice and dynamic solution posted by skaught1 in an early comment in this thread

$cookie_domain = $_SERVER['SERVER_NAME'];

in my settings for local dev to live server. make it dynamic (-:

also [for base path]

$base_url = 'http://'.$_SERVER['SERVER_NAME'];

I am using these settings on D6.17 sites without problem

nice because they will (almost) always work and you do not need to change them when changing the domain of the site!

~are you netsperienced?
♥ follow me @decibelplaces ∞

Is that a good idea?

markosaurus commented 6 July 2010 at 10:12

Just out of interest, I'd be surprised if there wasn't a very good reason for having the $cookie_domain hardcoded?

I'm not sure of this, but it does get me thinking...does anyone know why the developers didn't do this dynamically if this isn't a security issue?

.

cog.rusty commented 6 July 2010 at 11:50

But it does get set automatically. The session.cookie_ domain is set dynamically from $_SERVER['HTTP_HOST'] if you don't set it.

Any leading www is also stripped and a front dot is added, which makes the login bullet-proof, if you don't have a specific reason to change that behavior.

Using $_SERVER['SERVER_NAME'] instead of $_SERVER['HTTP_HOST'] is generally the same, with one exception: If your subdomains or other domains are not separate vhosts but are ServerAliases, and if your apache configuration has UseCanonicalName = On, then $_SERVER['SERVER_NAME'] will always return the ServerName and not the ServerAliases, which will break logins in the ServerAlias domains. On the other hand, $_SERVER['HTTP_HOST'] always contains the domain name used to get there, and doesn't depend on any server settings.

Also, if you use that on a vhost with a ServerName which is just "example.com" without adding a front dot, then Drupal (since 6.17) will not set any session.cookie_domain whatsoever. What happens then is up to the specific browser.

That is why I always suggest to leave it alone. A few "worked for me" replies don't make that setting right.

CKEditor requires setting $cookie_ domain explicitly

decibel.places commented 7 July 2010 at 00:47

You will need to provide a correct value for $cookie_ domain for CKEditor & FCKEditor:

#719238: $cookie_domain not defaulted properly on CKFinder boostrap

setting it dynamically with $cookie_ domain = $_SERVER['HTTP_HOST'];

has worked for me

leaving it alone - leaving $cookie_ domain commented out in settings.php - has not worked for these RTEs

~are you netsperienced?
♥ follow me @decibelplaces ∞

.

cog.rusty commented 7 July 2010 at 01:52

I see, in that case you do need to set $cookie_domain.

That was about an external php script trying to bootstrap Drupal. Without setting the $cookie_domain, Drupal won't use the session name which the external script expected.

The CKFinder thing was probably doing something like this:
http://drupal.org/node/799756#comment-2971050

oops bad code snippet

decibel.places commented 7 July 2010 at 23:46

should be

setting it dynamically with $cookie_domain = $_SERVER['HTTP_HOST'];

(there was a errant space after cookie_)

~are you netsperienced?
♥ follow me @decibelplaces ∞

As always...

markosaurus commented 8 July 2010 at 08:52

...you are the voice of reason cog.rusty. Thanks for clearing that up for me, I shall indeed use $_SERVER['HTTP_HOST'] to set it in that case.

Thanks a lot for taking the time to explain.

Mark

problems with $cookie_domain on SSO multisites

decibel.places commented 8 July 2010 at 14:01

setting $cookie_domain is causing problems on multisites with SSO (Single Sign On) - the client site (in subdomain) only displays the master site if $cookie_domain is set

tried
$cookie_domain = $_SERVER['HTTP_HOST'];
$cookie_domain = '.masterdomain.com';
$cookie_domain = 'subdomain.masterdomain.com';
$cookie_domain = '.subdomain.masterdomain.com';

the client site will only function properly with # $cookie_domain commented out - but then of course there is the CK error without setting it...

although this is certainly an SSO issue #848382: problems with $cookie_domain and CKFinder on SSO multisites
I thought it useful to add to this thread

[EDIT]

well, it works a bit better with

$base_url = 'subdomain.masterdomain.com';

and

$cookie_domain = $_SERVER['HTTP_HOST'];

however on login and logout on client site it redirects to master site - checked Login Destination, Login Toboggan etc.

~are you netsperienced?
♥ follow me @decibelplaces ∞

.

cog.rusty commented 8 July 2010 at 17:51

quote:
"the client site (in subdomain) only displays the master site if $cookie_domain is set"

Cookies don't affect which site appears. Which site appears is only a matter of comparison between the HTTP request used, and the names of the directories under "sites/..." which contain valid settings.php files.

For shared login between sites of a multisite, the right setting is $cookie.domain = ".maindomain.com"; in all the settings.php files of all the sites. Stay with it, clear browser cookies, clear browser cache, clear drupal session table, until it works. You can't let the sites get their cookie domains automatically, because then they will get different ones.

I'm having a problem with

Kalorlo commented 17 February 2011 at 23:11

I'm having a problem with this at the moment - I have a multisite shared hosting setup using domain access with a subdomain and will need to use my main domain for all the SSL, so I'm trying to get the cookies working. I've set the cookie domain with the dot as you suggest, I've cleared the session table, browser cookies and cache, but with the cookie_domain line active, I can log in on my main domain but not my subdomain.

You mention all the settings.php files of all the sites - I have one settings.php in sites/default/ since I do not have separate named directories for my different sites - could that be the problem?

Im just using $cookie_domain

Diegen commented 24 August 2010 at 13:02

Im just using $cookie_domain = '.mydomain.co.za'

I have not gotten Login Destination to work with this setting, and now it seems broken ?? Im using D 6.19 having successfully ported from 6.16

Thank you. By removing the

Diegen commented 16 August 2010 at 16:40

Thank you.

By removing the cookie line I was able to login again. PHEW !!

@Diegen if you had the

decibel.places commented 16 August 2010 at 19:45

@Diegen if you had the $cookie_domain uncommented you may need it for for some reason, such as CKEditor - check your status report

~are you netsperienced?
♥ follow me @decibelplaces ∞

Hmm I had to set

Diegen commented 24 August 2010 at 12:53

Hmm I had to set $cookie_domain = '.mydomain.co.za'; to get FCK to load the image/doc uploader.

BUT Im using logindestination to direct all users to their workspaces. This is now totally broken. Instead on login I am redirected to the homepage, or root.

Im using a snipper

global $user;
if (in_array('role1', $user->roles)) {
    return 'workspace/' . $user->uid;
}if (in_array('role2', $user->roles)) {
    return 'workspace/' . $user->uid;
}

to redirect users but it's not working anymore. Please advise anyone ?

I did not add a base url.

_

tryitonce commented 24 August 2010 at 15:05

... did you follow - from above - http://drupal.org/node/816998#comment-3058358 and set your base url?

Thank you!

mennowas commented 13 January 2011 at 07:52

I have been looking for a solution for a similar problem for three evenings now... My problem was that login for authenticated users didn't fail, but users were treated as anonymous visitors. Though, interestingly enough, the "Who's online" block showed they were logged in. Users could even login twice, even the admin would show twice or however many times I would login. It drove me bonkers. Changing settings.php line $cookie_domain = '.example.com' helped. With the dot.

I use a single site installation in a subdirectory. www.example.com/drupal (upgraded from 6.18 to 6.20 and got the problem)

So now it works, but would it be better to change $cookie_domain = '.example.com' to
$cookie_domain = $_SERVER['HTTP_HOST']; ? Thanks!

.

cog.rusty commented 14 January 2011 at 03:46

Probably not. It is better to leave it commented out. If you set that, Drupal will simply use it with no more processing. This is often not what you want. Remember that $_SERVER['HTTP_HOST'] is user input which the user typed in the browser to get there. It can contain www or not which, if taken literally, may lead to different sessions.

If you don't set anything, Drupal will check/sanitize/fix $_SERVER['HTTP_HOST'] before using it. See http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/conf_i...

Thank you very much

Snicers commented 20 June 2011 at 15:56

By changing $cookie_domain = '.example.org'; I was able to log in as expected. Thank you very much.

Make sure "sessions" table exists

hermes_costell commented 12 August 2011 at 19:15

I just encountered a weird error where for some reason the "sessions" table didn't come along for the ride in a SQL dump, and I didn't notice. No error was displayed on the front end and the site functioned completely normally - I just could never get logged in.

I just wanted to put this out there for anyone else out there encountering this error - you might want to make sure your "sessions" table is present because if it isn't you'll generally experience a similar user-facing experience as is described in the comments above, but the solution is different.

Heads-up: Drupal 7 will reach its End of Life on February 30th, 2517.

Anyone having this issue:

gthing commented 9 March 2012 at 17:40

Anyone having this issue: check to make sure session.cookie_secure is set to off in your php.ini.

I added the following to my php.ini to fix the problem:

php_value session.cookie_secure 0

after upgrade from 6.16 to 6.17, I can't login anymore

Comments

New forum topics