"You are not authorized to access this page." immediately after logging in with any user

Question

I'm getting the seemingly famous You are not authorized to access this page. message whenever I log in to my local development environment from /user or from /user/login. I'm on Drupal 7.26, PHP 5.6.3, running under XAMPP 3.2.1.

I've tried clearing all browser history, truncating flood and session tables, making sure I'm not defining $cookie_domain. I'm sure I've tried other things, but nothing seems to work. What should I try next?

This is one of those "this worked yesterday" things that became one of those "I was sure I fixed this but I have no idea how" things.

edit: So I ran the following to disable most of the modules and then logging in worked again:

drush @alias pm-list --type=Module --no-core --status=enabled | sed 's/.*(//' | sed 's/).*//' | sed '/^ *$/d' | sed '/^.*views.*$/d' | sed '/^.*entity.*$/d' | sed '/^.*ctool.*$/d' | sed '/^.*ctool.*$/d' | sed '/^.*date.*$/d' | sed '/^field_collection$/d' | sed '/^link$/d' | sed '/^youtube$/d' | sed '/^block.*$/d' | tail -n+2 > modules.txt; cat modules.txt
drush @alias dis `cat modules.txt`
drush @alias cache-clear all

I did have some issues such as Fatal error: Call to undefined function entityreference_get_behavior_handlers() in entityreference_schema(), which is why that command is so ugly. (I'm sure there's a neater sed command.) Now I'm turning on the modules one at a time.

edit: Disabling all modules and then re-enabling all modules except for the libraries module and modules that depend on allows us to log in again. However, enabling that module breaks logging in. This problem is only in our local development environments, not our hosted environments.

Answer 1

Backup the database and rebuilt the permission of the user under "/admin/reports/status/rebuild"..

Answer 2

This issue might be a variation of the question about "drupal /?q=user is working but /user not working". So verify if you can use an URL containing ?q=user or ?q=admin. If that gets you going, then probably tuning RewriteBase in your .htaccess (as described in the accepted answer of that question) should help.

It might be worth trying to further enhance your .htaccess file, by adding a line after that existing RewriteBase, which looks like so:

RewriteRule . index.php [L]

For more details on the above line, refer to the (accepted) answer in this question on StackOverflow.

Another option for debugging is to retry using another browser. If via that brower you are able to login, then it's probably a cookie problem (in your original browser).

Update: as per the extra comment you added (with that 'Warning' you mentioned), you may want to look at Warning: "Headers already sent" or "Cannot modify header information", which contains 3 typical reason that cause these errors, and how to resolve them. Here is a summary of that link:

• it means that somewhere in the code, something was printed to the browser before Drupal had finished preparing the page. This is most often caused by custom or modified code contributed from sources outside Drupal, so inspect your uniquely added code (including themes) first ...

• Cause 1: If this error is not the first error message on the page, then it is most likely a 'avalanche effect' of previous errors and you may ignore it. Instead, focus on fixing the errors before it. When you fix the first error message(s), the "Headers already sent" error(s) will most likely disappear.

• Cause 2: Text editors sometimes insert a UTF-8 byte order mark at the top of a file. In this case, the error message will usually say that "output started" at line 1 of some file. To fix this, configure your text editor to save the file without a byte order mark.

• Cause 3: If you get an error "Headers already sent" as the first error and it tells you the error is near the end of a file (check which file "output started at" points to), that probably means that there are extra spaces or lines after a closing ?> php tag. In Drupal coding standards, it is strongly recommended (for this very reason) that PHP files should not have any closing ?> tags. to fix this, just delete them, and everything should work fine.

Notes:

1. Extra whitespace being added probably is caused by a bad unpacking program and / or a non-compliant editor (Windows Notepad or Wordpad, Mac TextEdit) adding it.

2. The question about Warning: Cannot modify header information - headers already sent contains some more details / hints that might help to understand what's happening, or to further debug it.