Sessions and uid problem

By rj.seward on 4 Jun 2008 at 15:16 UTC

I have a fairly new Drupal 6 site up and I am getting an unusual problem with sessions.

For example, today I was logged in as superuser with uid of 1 and there was just one session showing in the sessions table of the Drupal db. Then I went to do some admin tasks when I got an Access Denied message. So I went back to the db and there was another session, this time with a uid of 0.

I changed the uid of this new session to 1 and after that I was able to access all of the admin things as normal. I can delete the original session as apparently some code has determined that the new session record is the one I am to be assigned with.

So why would drupal suddenly create a new session for me? And why with uid of 0?

Has anyone else come across this type of problem before? What could be causing this?

Thanks in advance.

rj.seward

Comments

session.inc

rj.seward commented 9 June 2008 at 13:41

Today I found a forum post at http://drupal.org/node/20397#comment-175577 where it was suggested that I upgrade my includes/session.inc file. As mine was version 1.44 and the latest version is 1.48 (found at http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/session.inc?revis...) I thought I would give this a try.

Now, after upgrading the session.inc to v1.48 the strange behavior in my sessions table along with the concurrent Access Denied problems appears to have been fixed. We'll see...

Access Denied again

rj.seward commented 9 June 2008 at 15:37

Update on this install: This last Saturday morning, I went to add a feed to my site's aggregator, this time from a host machine outside my office, and I got the Access Denied error again. Again I found a second session record with uid 0 added to the db sessions table, and again I was able to gain access to the admin functions by changing the uid of the new session to 1.

While this workaround suffices for me, in a production environment this Access Denied / new session with uid 0 could be a major problem.

Any new ideas?

rj.seward

Once you have been

gpk commented 9 June 2008 at 17:56

Once you have been unceremoniously logged out can you just log back in again? (Not the point of your question I know ...)

Very occasionally I've found that what I thought was an existing session seemed not to be picked up and my session turned into one for an anonymous user. But this has never happened in the midst of using the site - only if I've been away from it for a while. Like you I found that I'd been given a new session with uid 0; actually my old session was still in the database and by editing the cookie on my local PC I was able to resurrect the old session. No practical use to this of course, but it suggests that perhaps either the browser failed to send the cookie, or it got lost in transit (not sure if this is possible), or it was mishandled by the server/PHP. I've not included the "Drupal got it wrong" option since I can't really see how this could happen: PHP hands the session ID on to the sess_read() function, which gets the corresponding session row out of the database, if such exists.

Next time this happens have a look and see if the old session row is still there.

I can't see anything in the D7 (HEAD) version of sessions.inc that would change the behaviour, unless you are on a very old version of PHP, in which case the HEAD versino would be worse.

HTH,

gpk
----
www.alexoria.co.uk

Old session row still there

rj.seward commented 9 June 2008 at 19:53

Re: Once you have been unceremoniously logged out can you just log back in again?
When this happens, it appears that I am logged out. If I go to the log in screen and enter my credentials, I am returned to the log in page, as though I had not logged in.

Re: Next time this happens have a look and see if the old session row is still there.
Yes, whenever this happens, the old session row is retained in the sessions table. I can delete this old session record with no apparent ill effect.

Re: by editing the cookie on my local PC I was able to resurrect the old session
Details on this please...

I have PHP Version 5.2.4 running under Apache 2.2.6 on my web server.

The possibilities then are:
browser failed to send the cookie
cookie lost in transit
cookie mishandled by the server (Apache here)
cookie mishandled by PHP
cookie dropped by Drupal code

I am using Firefox, and I don't see why Firefox would establish a session/cookie and then drop it. Usually I have to manually tell Firefox to clear out cookies, and in this case it appears to happen without my telling it to do so. I do not seem to have this problem with any other web site, so Firefox would not be a prime suspect in this case.
I have looked at my web server's httpd.conf but I don't see any directives for sessions or cookies.
The web server's php.ini has session directives such as:

; Whether to use cookies.
session.use_cookies = 1

; Lifetime in seconds of cookie or, if 0, until browser is restarted.
session.cookie_lifetime = 0

; Define the probability that the 'garbage collection' process is started
; on every session initialization.
; The probability is calculated by using gc_probability/gc_divisor,
; e.g. 1/100 means there is a 1% chance that the GC process starts
; on each request.
session.gc_probability = 1
session.gc_divisor = 100

; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 3600 (I just upped this from 1400)
etc.

.htaccess shows the following:
# PHP 5, Apache 1 and 2.

php_value magic_quotes_gpc 0
php_value register_globals 0
php_value session.auto_start 0
...

See anything unusual here?
How can I test these to see where the session is getting dropped?

OK this sounds quite

gpk commented 9 June 2008 at 22:20

OK this sounds quite different from any glitches I may have had.

>Re: by editing the cookie on my local PC I was able to resurrect the old session
Details on this please...

I think I used the Cookie Editor plugin for Firefox.

>Re: Next time this happens have a look and see if the old session row is still there.
Yes, whenever this happens, the old session row is retained in the sessions table. I can delete this old session record with no apparent ill effect.

The only effect from deleting a row (or rows) from the {sessions} table is to terminate the session(s) corresponding to the relevant row(s). i.e. you become anonymous again.

>Re: Once you have been unceremoniously logged out can you just log back in again?
When this happens, it appears that I am logged out. If I go to the log in screen and enter my credentials, I am returned to the log in page, as though I had not logged in.

So are you completely unable to log in again? What about from other browsers/computers/different location?
Cookie problems can get a bit of a headache, you might want to have a look round other posts here about the login problem. That sounds as though the session is just not sticking at all (i.e. you log in but then get a new anonymous session id ... worth checking in the sessions table exactly what is happening - i.e. when you have this problem do you get a new session id with every page request?)

What contrib modules are you using?

gpk
----
www.alexoria.co.uk

Cookies and logging in again

rj.seward commented 10 June 2008 at 19:26

First, thank you for taking the time to look at this.

Re: So are you completely unable to log in again?
Not until I change the uid value of the current session record in the session table to 1. It is really a bit strange since an invalid login will kick out an error, but in this case Drupal appears to accept the login as valid, but does not actually log me in. It is as if I am being told, "OK, you're logged in now, but you're still anonymous." A log entry from my site shows where login failed for me, but User is anonymous:
Type: user Date: 06/06/2008 - 15:40 Message: Login attempt failed for ralph. User: anonymous (not verified)

Here is a corresponding record from watchdog table in my drupal db:
wid: 1101 uid: 0 type: user message: Login attempt failed for %user.
variables: a:1:{s:5:"%user";s:5:"ralph";} severity: 5 location: http://scis.wju.edu/drupal6/node?destination=node referer: http://scis.wju.edu/drupal6/ hostname: 65.24.74.25 timestamp: 1212781232

Re: What about from other browsers/computers/different location?
I am able to access the site and login normally from another browser during such an episode.

Re: when you have this problem do you get a new session id with every page request?
No.

The good news is that this happens only occasionally and much less frequently since I upgraded my session.inc file. I am more concerned about the possibility of this occurring to someone other than myself. I work with a university, and one of the Computer Science professors here is considering teaching the Advanced Web Design course with the requirement that each student set up a site using Drupal 6. So, I am a little nervous about this problem cropping up unexpectedly. If I knew the cause, and hopefully thereby a preventative, I would be somewhat more assured.

Possibly significant: I experimented and found that both Firefox and Safari seemed to have this problem, whereas Opera apparently does not.

Contrib modules: CCK, Views, Advanced Help, AWStats, DHTML Menus, FCK Editor, Mollom

Well this is getting more

gpk commented 11 June 2008 at 13:04

Well this is getting more mysterious. The "Login attempt failed" message means that an invalid username/password pair was entered... You either get that one in watchdog or the one saying "Session opened for ...". You should also get an error message on screen if you enter invalid username/password.

If you get neither message in watchdog it suggests that the login routine was not called and that your login form data (username/password) was not received by Drupal. Either the browser on this particular computer is playing up, or an unusual cacheing problem between you and the the server is causing incorrect behaviour, or else there is something strange about the server setup that is interfering with correct operation.

I'd actually suggest trying the site on a different server to see if that helps. I've always found Drupal pretty stable (as in, rock-solid). However, it can't compensate for all problems that can occur on servers or with particular ISPs, though it tries pretty hard to do so!!

Also I can't imagine that the newer sessions.inc (which belongs to a different version of Drupal) is making any real difference. BTW your original version should have been 1.44.2.1. Diffs from 1.48: http://cvs.drupal.org/viewvc.py/drupal/drupal/includes/session.inc?r1=1....

HTH

gpk
----
www.alexoria.co.uk

Watchdog log entries

rj.seward commented 12 June 2008 at 13:40

Here is the complete log of watchdog entries for this login period up to the mysterious logout. My apologies if this seems like more information than you wish to see but it does show something interesting - that my first session was closed by admin/user/permissions then a new session opened:

wid uid type message variables severity link location referer hostname timestamp

1101 0 user Login attempt failed for %user. a:1:{s:5:"%user";s:5:"ralph";} 5 http://scis.wju.edu/drupal6/node?destination=node http://scis.wju.edu/drupal6/ 65.24.74.25 1212781232

1102 1 user Session opened for %name. a:1:{s:5:"%name";s:5:"ralph";} 5 http://scis.wju.edu/drupal6/node?destination=node http://scis.wju.edu/drupal6/node?destination=node 65.24.74.25 1212781245

1103 1 user Session closed for %name. a:1:{s:5:"%name";s:5:"ralph";} 5 http://scis.wju.edu/drupal6/logout http://scis.wju.edu/drupal6/admin/user/permissions 65.24.74.25 1212781487

1104 1 user Session opened for %name. a:1:{s:5:"%name";s:5:"ralph";} 5 http://http://scis.wju.edu/drupal6/aggregator/sources?destination=aggreg... http://scis.wju.edu/drupal6/aggregator/sources 65.24.74.25 1212782074

1105 0 access denied admin/content/aggregator N; 4 http://scis.wju.edu/drupal6/admin/content/aggregat... http://scis.wju.edu/drupal6/aggregator/sources 65.24.74.25 1212782120

I believe the first login attempt failed due to my misentering of the password.

What happened is essentially this. I logged in and everything looked fine - admin menus accessible, etc. Then went to add a feed to LA Times and that's when I got this Access Denied message. Apparently, behind the scene, my session was closed and then reopened.

Has anyone ever seen this kind of behavior anywhere else?

Same experience

tagawa commented 12 June 2008 at 14:00

This seems to be similar to what I'm experiencing. Since last weekend logging in as administrator (or anyone) has resulted in the login form innocently reappearing with no error message. As other people have stated, I'm sure this is because of PHP being upgraded by my ISP.

Following other suggestions I checked the sessions table and although there's a record for UID 1, the most recent session always belongs to UID 0. If I delete this record and refresh the page a new UID 0 session is recreated immediately. I can only access the admin area if I change the UID from 0 to 1.

I have tried clearing out the browser cache and private data, tried a different browser and a different machine and tried updating includes/sessions.inc from version 1.44 to 1.48 but no luck.

Sorry I'm not able to offer anything new to this thread, just a bit of sympathy and another request for help. This seems prevalant but with no proper solution.

Permissions perhaps

rj.seward commented 12 June 2008 at 15:09

Since the problem seemed to begin when admin/user/permissions closed my session, I just looked at the settings under Administer>User management>Permissions. What I found there may help to explain this problem. I found that for the Aggregator module I had multiple permission boxes checked - among them the one for administrator, and another for user, which I had defined as a custom role. I suspect that this was causing the problem, at least in part.

I have now eliminated all but one of the check boxes, allowing authenticated user to access news feeds and allowing administrator to administer the news feeds. I also deleted the role "user".

Hopefully this should make things a little easier for the code when attempting to determine who is authorized to access or administer any given module or content.

This is from http://drupal.org/node/22275: "Although all roles you create yourself receive any permissions you give to authenticated users automatically, neither roles you create yourself nor the authenticated user role receives permissions given to anonymous users." Confusing, huh?

Other than the above, I believe all permissions are "cascading" meaning that an administrator (and anyone else except for anonymous) receives all the permissions of an authenticated user and so giving a specific permission to authenticated user automatically gives the same to administrator, as well as to anyone else who is logged in.

Thus we need only check one box to distribute permissions to anyone logged in. And to administer something we can just check the box for administrator. My experience with this login problem would appear to indicate that we should check the least number of boxes possible - like usually one to assign or distribute permissions. Otherwise the permissions checking code gets confused...

Well after all that

rj.seward commented 12 June 2008 at 21:19

Well, after trying all of the above, this crazy login problem is happening again.

Here are the latest watchdog entries:
wid uid type message variables severity link location referer hostname timestamp
1254 1 user Session opened for %name. a:1:{s:5:"%name";s:5:"ralph";} 5 http://mysite.com/admin/settings?destina... http://mysite.com/admin/settings 172.18.2.170 1213294856
1255 0 access denied admin/settings/fckeditor/edit/Advanced N; 4 http://mysite.com/admin/settings/fckedit... http://mysite.com/admin/settings/fckedit... 172.18.2.170 1213295068

and here are the current two session records:
uid sid hostname timestamp cache session
1 q901i153lgl2efvbs4u5k2f450 172.18.2.170 1213294861 0
0 dgobeidnrmgk0jncvbm5v29rh1 172.18.2.170 1213295068 0

The session with uid 1 is the session created when I logged in. The second one with uid 0 is the one that mysteriously appeared and by which I am now judged to be unfit to access any admin sections.

Again, the only way I know to get around this is to change the uid of the second session to 1. But that is really just a crude hack to get around a very real problem which is really quite annoying.

Thanks for the detailed

gpk commented 12 June 2008 at 22:36

Thanks for the detailed troubleshooting info.

OK what those 2 watchdog entries tell me is that 212 seconds after you logged in you tried to access the listed fckeditor admin page but your logged in status was "lost" because the "connection" between you and your session (the one with uid=1) was "mislaid" somehow. As I've said already, I think it highly unlikely that Drupal is getting confused ... what is supposed to happen is that PHP gives Drupal your session id (this is sent by your browser using the cookie) and Drupal matches this to the row in the {sessions} table, where we can clearly see that uid is 1 (for the original session). I've posted a link to the Drupal code that does this in one of the replies above. There are no ifs and buts and there is no conceivable way that this could sometimes work and sometimes not, unless PHP or MySQL are behaving in a highly non-deterministic way when performing simple queries and other basic operations.

If I am correct then the problem lies either on your PC, between your PC and the server, or on the server. I have heard of problems with cookies and PHP before; however at this stage it's not possible to say if that's where the problem is. If you can reproduce the problem using a different browser on a different computer on a different internet connection then it would point more and more to a problem with the particular setup/configuration on the server (and maybe the problem only happens when the server is very busy or something ...). If it's any reassurance, many many thousands of sites are using Drupal and *not* having this problem at all. Again, temporarily tranferring a copy of the site to another server would be a useful test. If you can try out these various options it would at least open up the possibility of saying with a bit more certainty *where* the problem lies, even if we can't pinpoint it exactly without further digging.

The reason I really don't think this is a Drupal bug is a bit like this: imagine a program that just printed "Hello world!". Suppose that very occasionally it didn't print anything at all. Does the program have a bug? ...? ...?

Once your session has been "lost" then as far as Drupal is concerned you don't have a session - you are a new visitor requesting their first page, so Drupal it creates a new session for you as an anonymous user and sends the new session id to your browser in the cookie. This is the new line in the {sessions} table. Assuming that this cookie is not lost, you should then see the timestamp in this new row updating each time you request another page. *You should be able to log in in the usual way*. In this case what should happen is that the uid in the new row gets updated to 1, and the session id should also be changed (regenerated). However if the server continues to lose cookies then you will see additional rows appearing in the {sessions} table instead.

BTW there is one possible situation in which this problem might "legitimately" occur, and that is if you access the site using 2 completely different domain names. Because cookies are matched to domain names (by default at least), and hence a session on domain1.com won't apply when accessing the site as domain2.com.

Finally, just to help clarify what I think is happening, I wouldn't call this so much a "crazy login problem" but a "crazy logout problem" in that you are getting summarily logged out on account of your cookie/session being lost/mishandled.

Hope this helps!!!

Best,

gpk
----
www.alexoria.co.uk

Back with another example

tagawa commented 14 June 2008 at 13:54

Having experimented a bit more, it seems this is unrelated to a particular PC setup - the same thing happens in Firefox & Opera on Linux at home and on Windows at work.

I have also just freshly installed Drupal 6.2 on an unused account with the same ISP I have the existing problem with and sure enough the login problem is there. I've made a guest account if you wish to try:

URL: www.eigoround.com
Username: guest
Password: guest

No content/themes/modules have been added to the site and it's running on PHP 5.2.6 and MySQL 4.1.22-standard. As you can see, the login is accepted but you are treated as an anonymous user, i.e. the newly created session with UID 0 overrides your real session.

The fact that this is suddenly happening on two separate accounts but with the same ISP (and same server setup) looks promising but I've seen people with similar problems with Drupal 4 and 5, PHP 4 and 5 and MySQL 4 and 5. There seems to be no consistency making it difficult to know where to start looking. It's a shame because when it was working Drupal was great and I'd like to stick with it.

Hi tagawa, at the risk of

gpk commented 14 June 2008 at 18:46

Hi tagawa, at the risk of stating the obvious, your problem seems specifically to do with not being able to log in??

I had a play around on your site ;) so you will see a number of sessions from my IP. Amongst other things I tried logging in with wrong password and got the expected error message “Sorry, unrecognized username or password…”

Session name in the cookie is consistently reported as SESS6d43b3ad880c848a30e98f05-------- so this is working OK :)

Then I cleared out cookies (so I would get a fresh cookie/session ID), went to home page, got session ID RpByEFG5CC-wXupILOHETPhfzzaMByWNkYT3Nqly29Spg33rO4PVx-Ge--------

Went to user register page, cookie (session) details stayed the same (this implies that sessions are working. If the cookie wasn’t being handled correctly at the server/Drupal end then Drupal would have issued a new session ID).

Went to login page at /user (could have gone back to home page I guess!), cookie/session details still the same, "logged in", didn't get error message, sent to page /user/3 (correct), got new session ID (this I would expect because it is regenerated (http://api.drupal.org/api/function/sess_regenerate/6) in http://api.drupal.org/api/function/user_authenticate_finalize/6), but of course I got the access denied message plus login box appearing on the left. The new session ID was q0eNmR_TQLdym8W-AW-JO4tznXNKgzx0stz22zyELtEXaeVlw-6pvzHg--------. What should have happened is that the old session row in the database should have had the old session ID replaced with this one, as you can see from the last line in the sess_regenerate() function.

So, in the sessions table, you should be able to see my current session ID beginning q0eN...

Can you see the one beginning RpBy... ? And are there any other extraneous sessions "between" them (try sorting by timestamp). Also if you have the statistics module enabled and are recording page hits then you can follow the flow in the {accesslog} table. What you would see there if everything is working is basically:

A hit as "anonymous" on the page where I logged in from (which was /user)
After I'd typed in user + pass and pressed login you should then see (a few seconds later) 2 hits almost simultaneous:
- another hit on /user but with new session ID and user ID of 3
- a hit on /user/3 with the same (new) session ID and user ID of 3

Also worth correlating all of this with the {watchdog} entries for logins etc.

HTH,

gpk
----
www.alexoria.co.uk

Thank you but...

tagawa commented 17 June 2008 at 22:44

Thank you for taking the time to investigate.

Firstly, in the sessions table there are three entries for your IP:

UID 0: 2UVwzXjxI9FNZjQzagbshxHRaWnLyMkkzEtsm616Mz3D1ar5PA... Timestamp: 1213466316
UID 3: 1d855f57de03921dc522e90bcbe383b3 Timestamp: 1213466807
UID 0: q0eNmR_TQLdym8W-AW-JO4tznXNKgzx0stz22zyELtEXaeVlw-... Timestamp: 1213466807

The statistics module wasn't enabled (it is now) but the watchdog table also has three entries for your IP:

UID 0: user Login attempt failed for %user. a:1:{s:5:"%user";s:5:"guest";} http://www.eigoround.com/node?destination=node Timestamp: 1213466316
UID 3: user Session opened for %name. a:1:{s:5:"%name";s:5:"guest";} http://www.eigoround.com/user Timestamp: 1213466807
UID 0: access denied user/3 N; http://www.eigoround.com/user/3 Timestamp: 1213466807

No sign of your RpBy... session. I'm not sure if that is significant - this is getting a bit over my head I'm afraid.
As far as I can see, the problem is the last unnecessary session being created with UID 0.

It seems to be working now

gpk commented 18 June 2008 at 12:45

It seems to be working now ... ! (Though the site hung on me a couple of times.)

gpk
----
www.alexoria.co.uk

Yes!

tagawa commented 18 June 2008 at 13:57

Hi again,

Yes, it's all fixed. I've been in touch with my ISP (www.arhoster.com in the UK - they're very responsive) and they commented out the PHP IfModule bits in .htaccess which did the trick. I've just gone and removed the # for the PHP 5 bit but left the PHP 4 bits commented out and it's still fine. Not sure if it's Apache or PHP 5 but something recently upgraded does not like the .htaccess reference to PHP 4.

Sorry for taking up so much of your time but hopefully others in the same position will see this thread.
Have a cool virtual beer on me...

Thank you very much.

Please clarify re: .htaccess

rj.seward commented 18 June 2008 at 19:18

This sounds interesting. Could you elaborate on what lines your ISP commented out and which ones you uncommented? It sounds like they commented any section that begins with <IfModule *> - which would effectively eliminate about 90% of my .htaccess.

You then uncommented which lines?

Perhaps you could post your .htaccess as it now stands for public comment and approval.

Thanks for the info...

Here you go

tagawa commented 19 June 2008 at 13:25

#
# Apache/PHP/Drupal settings:
#

# Protect files and directories from prying eyes.
<FilesMatch "\.(engine|inc|info|install|module|profile|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(code-style\.pl|Entries.*|Repository|Root|Tag|Template)$">
  Order allow,deny
</FilesMatch>

# Don't show directory listings for URLs which map to a directory.
Options -Indexes

# Follow symbolic links in this directory.
Options +FollowSymLinks

# Customized error messages.
ErrorDocument 404 /index.php

# Set the default handler.
DirectoryIndex index.php

# Override PHP settings. More in sites/default/settings.php
# but the following cannot be changed at runtime.

# PHP 4, Apache 1.
#<IfModule mod_php4.c>
#  php_value magic_quotes_gpc                0
#  php_value register_globals                0
#  php_value session.auto_start              0
#  php_value mbstring.http_input             pass
#  php_value mbstring.http_output            pass
#  php_value mbstring.encoding_translation   0
#</IfModule>

# PHP 4, Apache 2.
#<IfModule sapi_apache2.c>
#  php_value magic_quotes_gpc                0
#  php_value register_globals                0
#  php_value session.auto_start              0
#  php_value mbstring.http_input             pass
#  php_value mbstring.http_output            pass
#  php_value mbstring.encoding_translation   0
#</IfModule>

# PHP 5, Apache 1 and 2.
<IfModule mod_php5.c>
  php_value magic_quotes_gpc                0
  php_value register_globals                0
  php_value session.auto_start              0
  php_value mbstring.http_input             pass
  php_value mbstring.http_output            pass
  php_value mbstring.encoding_translation   0
</IfModule>

# Requires mod_expires to be enabled.
<IfModule mod_expires.c>
  # Enable expirations.
  ExpiresActive On

  # Cache all files for 2 weeks after access (A).
  ExpiresDefault A1209600

  # Do not cache dynamically generated pages.
  ExpiresByType text/html A1
</IfModule>

# Various rewrite rules.
<IfModule mod_rewrite.c>
  RewriteEngine on

  # If your site can be accessed both with and without the 'www.' prefix, you
  # can use one of the following settings to redirect users to your preferred
  # URL, either WITH or WITHOUT the 'www.' prefix. Choose ONLY one option:
  #
  # To redirect all users to access the site WITH the 'www.' prefix,
  # (http://example.com/... will be redirected to http://www.example.com/...)
  # adapt and uncomment the following:
  # RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
  # RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]
  #
  # To redirect all users to access the site WITHOUT the 'www.' prefix,
  # (http://www.example.com/... will be redirected to http://example.com/...)
  # uncomment and adapt the following:
  # RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
  # RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]

  # Modify the RewriteBase if you are using Drupal in a subdirectory or in a
  # VirtualDocumentRoot and the rewrite rules are not working properly.
  # For example if your site is at http://example.com/drupal uncomment and
  # modify the following line:
  # RewriteBase /drupal
  #
  # If your site is running in a VirtualDocumentRoot at http://example.com/,
  # uncomment the following line:
  # RewriteBase /

  # Rewrite URLs of the form 'index.php?q=x'.
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>

# $Id: .htaccess,v 1.90 2007/10/05 14:43:23 dries Exp $

My ISP commented out all three PHP/Apache "IfModule" sections but I've re-enabled the PHP 5 bit (# PHP 5, Apache 1 and 2) and it still seems OK. I've also tried enabling some of the other Rewrite bits (www redirect) with no adverse effects. The safest course of action seems to be customise .htaccess to suit your specific version of PHP and Apache and start from there.

Hope this helps.

Thanks

rj.seward commented 19 June 2008 at 20:08

I commented out the lines in my .htaccess file as directed above. I will see if this is a permanent fix.

Update on this

rj.seward commented 10 July 2008 at 14:52

My site has been behaving - mostly - for several weeks. This morning, however, the problem started happening again and my D6 site was doing weird things like appearing to accept my log in but returning me back to the anonymous/login screen and denying access to any admin pages. I had previously created a non-admin user and I tried logging in through this user, but the problem was the same in that this user's login appeared to have been accepted but was returned to the anonymous/login screen.

I still have not nailed the cause of this problem down and the only solution I have thus far is to go to the database sessions table and do either of:
1) delete all session records, clear your browser's cache and then try logging in again
2) determine which session record is currently assigned to you and change the uid to 1

Recently while I was showing my boss a module I had been working on I logged in and got hit with the Access Denied message again. Really embarrassing.

If there anyone knows of a hack to work around this, I would really appreciate if you would share it.

Finally figured this out

rj.seward commented 11 August 2008 at 15:40

Well, I think I have finally figured this out. It appears that the problem was the permissions granted to the drupal user in mysql. It seems I had granted all of the permissions I thought drupal would need but omitted one or two like ALTER and DROP. This apparently caused the strange behavior with the login.

This is from http://drupal.org/getting-started/5/install/create-database/mysql:

"At the MySQL prompt, enter following command:
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER, CREATE TEMPORARY TABLES, LOCK TABLES ON databasename.* TO 'username'@'localhost' IDENTIFIED BY 'password';
...
Unless your database user has all of the privileges listed above, you will not be able to run Drupal."

Drupal 6 core needs two less permissions as per http://drupal.org/getting-started/6/install/create-database: "GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER". I granted all the permissions as for D5 above - just to be sure.

Now everything has been behaving rather well. My apologies to all. The moral of this story is the read and follow the instructions carefully when doing the initial setup. Otherwise you can spend days and weeks in hell trying to track down the problem.

Ahhhhhhhhh..............!!!

gpk commented 11 August 2008 at 16:49

Ahhhhhhhhh..............!!!

I don't quite see how not having ALTER and DROP permissions would cause a sessions problem but hey! Glad it's all working now! Even in D6 you might want to assign the DB user the fuller set of permissions if you can since contrib modules might need them ..

gpk
----
www.alexoria.co.uk

A final statement of resolution

rj.seward commented 26 January 2009 at 15:24

As a follow up to this issue, I wanted to post the following update.

I recently upgraded my server to Fedora 10 from Fedora 6. This upgrade was accomplished by backing all of my essential data, doing a fresh install of Fedora 10, then restoring all of the data and reinstalling / reconfiguring all of the essential operations.

In the course of this reconfiguration, I reviewed my server's php.ini file and compared the new ini with the old. In the old ini file, I noticed that there were some directives in the [Session] section which may have been causing problems. These were:

1) session.save_path = "/var/lib/php/session"
which may have been causing a read/write permissions issue so I changed this to:
session.save_path = "/home/session"
and I made sure apache had read and write permissions to this directory.

2) session.cookie_lifetime = 0
This is "Lifetime in seconds of cookie or, if 0, until browser is restarted." In the current php.ini this is set to:
session.cookie_lifetime = 1440
This translates into 24 minutes and could set higher, but 1440 seems to work so...

3) session.cookie_httponly =
This line is absent altogether in the current ini file.

4) session.cache_limiter = none
whereas the current ini file has this as:
session.cache_limiter = nocache
(I'm not sure how significant this is)

The good news is that now the problem I was having previously with strange, unintended logouts has completely evaporated. It was still happening occasionally even after I modified the drupal mysql permissions as per my previous post.

So, if anyone is having a similar problem, my suggestion is to pay close attention to where and how sessions are being stored on your server machine, and check out your php.ini file.

And my deepest thanks and appreciation to all who contributed to this topic.

rj.seward

Congratulations!

tagawa commented 27 January 2009 at 01:29

Phew - must feel good to close that chapter!

Thanks for posting your findings and glad your perseverance paid off.

Amen

rj.seward commented 26 February 2009 at 16:09

Yes. Thank you and Amen.

Seconded

gpk commented 27 January 2009 at 15:15

A friend did once mention there could be issues with PHP's handling of sessions in certain versions which were very hard to get to the bottom of.

Anyway, for now, :-D

gpk
----
www.alexoria.co.uk

Had this same problem - FIXED!!!

mckinleymedia commented 11 December 2013 at 18:21

--- TRUNCATE the sessions table! ---
My Drupal 6 build suddenly stopped any user from accessing the back-end - it had been working for years. When I tried to log in, I would get "Access Denied." I was able to determine that logging in was working by checking the last login timestamp in the user table. Something else was stopping me.
I too tried many things. In the end, it appears that "Truncating" the "drp_sessions" table did the trick. I had 90 pages of sessions in the db. I also "truncated" all "_cache" tables, ran cron, edited my php.ini file a little, changed the sessions folder permissions to 777(probably not a great idea) and cleared my browser cache, but I think the sessions truncate did the trick.
I hope this helps.

Sessions and uid problem

Comments

session.inc

Access Denied again

Once you have been

Old session row still there

OK this sounds quite

Cookies and logging in again

Well this is getting more

Watchdog log entries

Same experience

Permissions perhaps

Well after all that

Thanks for the detailed

Back with another example

Hi tagawa, at the risk of

Thank you but...

It seems to be working now

Yes!

Please clarify re: .htaccess

Here you go

Thanks

Update on this

Finally figured this out

Ahhhhhhhhh..............!!!

A final statement of resolution

Congratulations!

Amen

Seconded

Had this same problem - FIXED!!!

New forum topics

News items

Our community

Documentation

Drupal code base

Governance of community