3

Drupal 7.5, PHP 5.6.27 Debian 8, remote host.

We are running into a problem where some people can't log in some of the time and sometimes it works if they try multiple times. Users have reported the issue with different browsers and only a small percentage of people seem to be affected. Please note that I can only reproduce the error on occasion, and very inconsistently.

Watchdog simply shows that a session is opened for the user, even if the front page shows that they are not logged in.

Edit: Users can usually log in if they enter the wrong password first!

Things I've tried:

  • changed cookie_domain from www. to .
  • made sure rewrite condition allows https
  • cleared Drupal cache
  • we have no external caching
  • added redirect from port 80 only to default-ssl.conf
  • Users can't always log in with a one-time log in link generated with drush uli "[username] (the site will ask them to log in)
  • creating a custom login module to set a new custom session suggested here
  • added some cookie configurations to the sites/default/settings.php file as suggested in this post
  • installed the website on a different environment with PHP 5.5 and different settings.php .htaccess and php and mysql configurations.

Known Workarounds: May or may not provide clues.

  • Sometimes if we change a user's password, they can get in that way
  • If a user enters the wrong password first on purpose then logs in, they are able to log in
  • Sometimes we can provide a one-time log in link for users to get in, but that doesn't always work

Edit: I've managed to recreate the issue on a local development environment with different settings files. I removed all the settings files information from my original post since I know now that they are not relevant.

Improve this question
9
  • 1
    Note: "Make sure to always start the $cookie_domain with a leading dot, as per RFC 2109." So it should be .example.com.
    – dxc
    Nov 8, 2016 at 7:02
  • 1
    Another thing to try would be to turn of any external cache. If you use something like Varnish this may cause users to see the "logged out" version even if they are logged in.
    – dxc
    Nov 10, 2016 at 20:51
  • It does feel a lot like HTTP > HTTPS bouncing as enzipher already described. The user first fills his credentials in the HTTP version of the site, the form submission then redirects to HTTPS (because of the base url) and a new session is started. To debug, see if the login page is accessible via HTTP as well. See Enabling HTTP Secure (HTTPS) for what to do. I recommend the last option to redirect all HTTP traffic to HTTPS. The required .htaccess lines are at the bottom.
    – Neograph734
    Jan 13, 2017 at 23:23
  • The site always comes up as https. If you attempt to go to http, it directs. When login fails for me, I make sure it's https.
    – Christia
    Jan 13, 2017 at 23:46
  • Can you provide a link to the site and a dummy username/pw ?
    – rémy
    Mar 15, 2017 at 0:11

3 Answers 3

Reset to default
3

That can happen if the site is redirecting to a different domain or to a secure/non-secure protocol upon login. I.e. with/without www or to http/https. If so, you could set a base domain and cookie domain in settings.php, and/or enable www/non-www redirect in .htaccess.

It also seems there may be a problem with PHP 5.6.1.
https://www.drupal.org/node/2723927
https://www.drupal.org/node/2379019

Improve this answer
1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Clive ♦
    Dec 15, 2016 at 21:14
3

I believe there is some kind of caching in play here. I've found that I can successfully log in with the demo user provided by generating unique login URLs. Each unique login URL I create has worked for me exactly one time and then no longer works after that. This strongly suggests that something is caching pages based on their URL and dynamic backend functionality (PHP) is no longer taking effect on subsequent attempts to log in via that URL.

For example.. I could not log in via /user/login, but when I manually switched that to /user, I was able to log in once, but after logging out, I couldn't log in via that URL anymore. I tried appending a series of ?itok=asdf query parameters to the login URLs and each would work once. Adding numbers at the end of the query string did not appear to work, so ?itok=asdf1 worked, but then trying ?itok=asdf2 did not, but ?itok=asd did.

I've already burned /user/login/a and /usr/login/b with further testing. To test this yourself, I suggest coming up with a unique alphabetical prefix and then alphabetically appending to that, e.g.

/user/login/prefix
/user/login/prefixa
/user/login/prefixb

... etc

Note again that in my testing each URL is working exactly once and "never" works again.. you must keep coming up with new ones to repeat the test.

As stated above, this strongly suggests something is caching pages based on the URL.

Improve this answer
9
  • 1
    Nice sleuthing!
    – Clive ♦
    Mar 17, 2017 at 18:45
  • Wonderful insight!! Any suggestions on where to go to look at caching functions? Would it be in php.ini, settings.php, an installed module in Drupal or on the server or any/all of those things? I'll try to index all of possible caching systems we have. (I have no documentation from the previous developer).
    – Christia
    Mar 17, 2017 at 20:03
  • 1
    I don't have good suggestions on where to "look". In these kinds of situations I look for ways to "split the problem in half" such that I can determine it is either "somewhere over here" or "somewhere over there". If it were me, the first thing I would try would be to test whether it's part of the system the site is on or if it's in the site code itself. I would do this by setting up another system to run the site, like a local development system (a Mac or a VirtualBox VM). Export DB, copy files, see if the problem repeats itself in the new environment.
    – adfaklsdjf
    Mar 18, 2017 at 17:27
  • 1
    If the behavior persists in a new environment, it's somewhere in the Drupal site code most likely. If the problem disappears, it's something in the system or network where the site is running. With complex systems like these, the most effective way to isolate a problem is with various tests to see if it's generally on this side of the test or that side. Wandering around through code hoping to stumble on the core problem can take months.
    – adfaklsdjf
    Mar 18, 2017 at 17:29
  • 1
    @Christia I personally would test as mentioned above, but to to answer your question more directly -- I don't expect it to be in php.ini or settings.php. My guess would be a Drupal module or an outside "reverse proxy". Consider asking your network people how requests get routed to your site. But hey, I could be wrong. Complex systems and all that.
    – adfaklsdjf
    Mar 18, 2017 at 23:00
0

If I can make a guess correctly, the users might have forgotten or entered a wrong password for 5 times which in turn will block access for over 6 hours. Post down the cool down period they'll be able to access. For immediate access, drupal developers need to clear there IP from the flood table in database.

Improve this answer
1
  • Hi, sorry. It's not that. This happens a lot on first-time logins, but also, if they get blocked out, they get an error message that tells them so. In case anyone finds this useful, if users get blocked out, you can clear the flood tables with drush: drush php-eval 'db_query("DELETE FROM 'flood' ");'
    – Christia
    Sep 5, 2017 at 22:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.