There are several reasons why a login doesn’t “take”; that is, despite entering the correct username and password, and being recorded as correctly authenticated in the watchdog, a user is not recognized as logged in. In some cases he or she will be recognized after refreshing the browser, and in some cases using the login link provided by “Request New Password” is sufficient, but in other cases the system continues to treat them as an anonymous user.

When a browser makes a request, Drupal checks to see if it has set an HTTP cookie in the browser, and compares it against sessions stored in its database. This process can be interrupted either in the browser, in the database, or both, preventing the authenticated session from persisting.

Cookies

If you are able to log in using one browser but not another from the same machine, the problem is most likely local.

• Make sure cookies are enabled in your browser.
• Make sure your firewall or ad blocker is not blocking or rewriting session cookies.
• Cookies are text files stored on the user's hard disk, and may get corrupted. Try deleting cookies for the site in question.
• Internet Explorer 6 was known to cause problems when its cache was full. Try clearing the 'Temporary Internet Files' folder(s).
  • MS Windows XP-SP3 - 'Temporary Internet Files' locations: d.o....node/1540356.

Logging in at www on a site with no www in the base URL

If a site is set with example.com as the base URL and the user instead browses to and logs in from www.example.com, a session cookie will be set for www.example.com. But the site will then forward the user to the non-www version, and the user will not be detected as logged in.

To avoid this problem, first decide whether the www or non-www version of the domain will be canonical, then redirect the other version. As of Drupal 6, settings to do so in Apache are provided in the .htaccess file ; uncomment the section that applies to you.

Second, the domain name for session cookies can be set explicitly in settings.php. For instance, if you want sessions from example.net to be recognized by gallery.example.net and forum.example.net, set $cookie_domain to .example.net. Note that the preceding dot is required as of Drupal 6.17.

If you have access to php.ini on your system, setting session.cookie_path = \ has also been reported to fix the problem.

Cache Problems

Sometimes the Drupal cache is not updated when logging into a site, so even after logging in the user is still shown the cached version of the site. Different reports have blamed various browser, web server, and Drupal settings. It should have been corrected in Drupal 5.7.

One solution seems to be to disable the Drupal cache of the site, though that has the undesired side effect of increasing the load on your site.

Another workaround is for the users to hit the browser refresh button which seems to work fairly well, but has the drawback of not being easily discoverable and is a hassle for every user of the site. On a site where only one or two users login, this is not a problem. On a community site it is a bigger problem.

See also

• Login doesn't "stick" after upgrade to PHP 5.2+
• Problem with login (doesn't seem to 'take')