By vincentv on

Running Drupal 6.9 on CentOS 5.2.

After installing Drupal as per the installation instructions, all seems to be OK for authenticated users, but anonymous users can't access anything.

After a lot of trying different options, I've reverted to whiping it all out (DB, directories, etc), and doing a virgin install.
I get the "Welcome to your new Drupal website!" page. When logging out, I immediately get the "Access denied" page.
I log in and create a page that I promote to the front page. I check if the anonymous user has the "access content" right. It has.
I log out and again get the "Access denied" page...

Again, this is a virgin install with no changes at all. So no caching, path module, or whatever.

I've checked for httpd errors, PHP errors, SELinux errors, MySQL errors, there are none.
I've disabled SELinux, given the apache user and even world all rights to all drupal files and dirs, to no avail.
The node_access table has the "0,0,all,1,0,0" record.
The status report is all green. Here it is for reference:

Drupal 6.9
Access to update.php Protected
Configuration file Protected
Cron maintenance tasks Last run 1 min 52 sec ago
You can run cron manually.
Database updates Up to date
Drupal core update status Up to date
File system Writable (public download method)
GD library bundled (2.0.28 compatible)
MySQL database 5.0.45
PHP 5.1.6
PHP memory limit 16M
PHP register globals Disabled
Unicode library PHP Mbstring Extension
Update notifications Enabled
Web server Apache/2.2.3 (CentOS)

Does anyone have a hint for me how to fix this? I've been struggeling with this for about five hours now and just can't seem to get it to work...

Thanks in advance,
Vincent

⋅ Categories: Drupal 6.x

Comments

cog.rusty’s picture

cog.rusty commented

Does the URL change in any way in the browser, for a page which is accessible to the admin and denied to the anonymous user?

Do you have any apache authentication directives in an .htaccess file in a parent directory?

Check your site's cookies in your browser. Are there more than one? Examine their contents for any differences between them, especially in their cookie domain name and in their cookie path.

vincentv’s picture

vincentv commented

Thanks for your answer!
I've checked your suggestions:

- The URL does not change in any way. The front page I've created is .../node/12 for both.

- There's no parent directory and there are no .htaccess files except the one in Drupals root

- Cookies for anonymous or authenticated users contain the same domain name and cookie path. There is only one cookie and the sessions register correctly in the sessions table.

Any onther suggestions would be more than welcome :)

cog.rusty’s picture

cog.rusty commented

Is there a user with uid=0 in your "users" table?
A role with name="anonymous user" in you "role" table?
(No role assignment required for this in the "users_roles" table.)

Does the domain name contain any underscore character?

vincentv’s picture

vincentv commented

Yep, both are there.
The uid=0 user row has no values but the default ones, but I guess that's correct.
The user_roles table is empty.
The domainname doesn't contain any underscores; see here: www.bbl40209.nl (you can register yourself here if you wish, to see the difference between auth and unauth).

vincentv’s picture

vincentv commented

Our DNS guys have created an A record for the www.bbl40209.nl site, byt that's a vitual host on an existing site. They should have created a CNAME record that points to the physical machine...
It has been corrected, I'll keep you posted.

vincentv’s picture

vincentv commented

Well, that wasn't it, obviously.
Anyone have any other ideas?

greg.1.anderson’s picture

greg.1.anderson commented

This looks like an affect I was seeing when I set session.cookie_secure to true; see my recent post:

http://drupal.org/node/380326

This is not necessarily your problem, though, as you probably wouldn't have gotten past the 'login' action if you had. If you had to fix login to make your system work, though...

vincentv’s picture

vincentv commented

Nope, phpinfo shows that it's off.

I'll keep looking...

vincentv’s picture

vincentv commented

OK, the issue has been solved and it is a nasty one.

The problem is that I have a two-way replicating MySQL DB setup and because of that, the "auto increment" does not increment by 1 on all systems, and the auto_increment offset isn't 1!
So, in the end my "role" table had a "anonymous user" role with an rid of 2 and a "authenticated user" role with a role id of 12.
I changed this to 1 and 2 respectively and the problem is gone. Anonymous users have access to what they should have access to.

I guess that somewhere in the Drupal code, it is assumed that the "anonymous user" role always has a role id of 1. Seems to be a false assumption...
The same assumption goes for "authenticated user". That is assumed to have a role id of 2, but on my system that is 12...

Nasty...

I guess someone should recode the corresponding code not to assume anything :)

cog.rusty’s picture

cog.rusty commented

You cheated! You kept some bizarre facts secret. :-)

Apparently it is the define('DRUPAL_ANONYMOUS_RID', 1); in http://api.drupal.org/api/file/includes/bootstrap.inc/6/source

Although your setup is a bit exotic, I think that assigning meaning to an autoincrement ID is a dubious practice. Luckily it didn't happen with user #1.

hendrakieran’s picture

hendrakieran commented

I'll be damned! I've hit the same problem and thanks to you, it's fixed now. May be drupal code shouldn't use auto increment value for IDs that they hard coded!