First of all, this module and its upshot is a very well idea. I wanted to use it and maybe even take part in development as far as can with my poor php knowledge. One thing I can do is to send one VERY CRITICAL bug report:

After some configuration on nodeaccess module I logged out and cannot login anymore.

Description of what I did

I installed nodeaccess module and ran the update script. I went to nodeaccess configuration and activated nodeaccess for 2 node types. I did no changes on configuration for page, story, forum and usernode.
I saw the grant tab for the node types I activated. I wanted to grant access to some users of a node. I got the message "Grants saved", but the names did not appear in order to be further configurable (I noticed the same effect on your test site).
I wanted to see what other users see. I logged out. I noticed, that none of the nodes I left untouched (page, story, forum , usernode) were shown on the frontpage anymore. After logging out, I could not login with any username. STILL I CAN NOT EVEN LOGIN WITH ADMIN ACCOUNT ANYMORE.

After clicking "login" I saw the login block again. I could invoke the process to let me send a new one-time-login. I used it but could not login again, message: Access forbidden. I don't see any possibility to get back access except reverting all changes nodeaccess module made on the drupal database.

Urgent question

  1. What changes do I have to do on my database to get back access and control of my site?
  2. What can one do to prevent this damage on order to take part in development?

Comments

marcor’s picture

marcor commented
Title: BEWARE THIS MODULE! Cannot login as admin after configuring nodeaccess » Cannot login as admin after configuring nodeaccess

100x I will always read the readme.txt first.
100x I will always backup my database before using access modules at development state ;)

While I didn't have access, access was still possible from another machine. Maybe this was an interaction with session, but I don't know.
Some unordered steps to (nearly) happyness:

  • delete nodeaccess table (warning: table node_access is part of drupal core. This needed the row
    nid    gid  realm grant_view  grant_update grant_delete
0        0    all      1          0         0

    to work correctly. And no more (for my site).

  • in variable table: delete all variables starting with "nodeaccess" ("nodeaccess_nodetype" and "nodeaccess-types")
  • clear cache by running update.php (disable access control by editing first row in file update.php - don't forget to enable it if everything works)

So I'm admin again. Hope that everything works again, but it looks good so far.

But still I don't know what I did wrong... :(

Anonymous’s picture

Anonymous (not verified) commented

There seem to be several issues here...

I saw the grant tab for the node types I activated. I wanted to grant access to some users of a node. I got the message "Grants saved", but the names did not appear in order to be further configurable (I noticed the same effect on your test site).

This works fine on the test site, did you check the box for keep? in order to save that entry?

I wanted to see what other users see. I logged out. I noticed, that none of the nodes I left untouched (page, story, forum , usernode) were shown on the frontpage anymore.

This is what would happen. This module grants access. In other words, it defaults to denying everyone access to everything (except the admin user) and only grants whatever access you have given. If you didn't grant any access to anyone for page, story forum or usernode, no one would be able to access it.

After logging out, I could not login with any username. STILL I CAN NOT EVEN LOGIN WITH ADMIN ACCOUNT ANYMORE. After clicking "login" I saw the login block again. I could invoke the process to let me send a new one-time-login. I used it but could not login again, message: Access forbidden.

While there's a .0001% chance I could be wrong on this, I really don't see how this module could cause this problem for two reason. First, to date there have been plenty of people running this module (I'd guess at least 100 based on the people I've heard from, and I'm sure more people use it than I've heard from). It seems to me that it'd be almost impossible for such a bug to exist and go unnoticed by so many people for months...

Secondly, code wise I just don't see how it could be possible. This module writes entries to drupal's node access table. Well actually in the 5.x version it uses drupal's API to do so. So it's main function is to use a core API. The api writes to a node_access table which is a core drupal table, which has no influence at all on user logins. The only other things this module does is to save a few variables, and to write some data to it's own table only used by the module. I can't see how either of these could cause users to be unable to login.

Lastly, if you could log in fine from another machine, I don't really see how that could be a drupal or module issue... Doesn't make sense...

marcor’s picture

marcor commented
Priority: Critical » Normal

Thank you very much for your detailed answers. I admit that I was not well prepared when I activated nodeaccess. But for me, things happend as described above. From a temporal point of view nodeaccess install was the cause. In fact, other causes are possible and even likely.

I see some interplay with other configuration I made before. But all other changes I made to that Drupal site happened a long time (and many, many positive login attempts) before. Once (a week before) I made a change on php session variables in order to fix an IE problem (according to an trustfully looking hint here).
I added this to settings.php:

ini_set('session.cookie_domain','www.mysite.org');
ini_set('session.auto_start', 0);

On my machine, routing prevents me from accessing the machine as 'www.mysite.org', I only access it via 'localhost'. This worked for weeks and I could login without problems.

After I ran into my described problem I deleted all nodeaccess stuff in the database and changed session workarounds back to default, ran update.php and restarted apache. Still same problem. Then, some hours later, I suddenly could login again from the original machine...

If nodeaccess is just having some changes on an own database table, I totally agree that there is no obvious reason that this depends on nodeaccess module. But for me it seems that (my inconsiderate) installing nodeaccess led to a fatal interaction with caching and session management. Could it be possible that nodeaccess installation is even more exhaustive than the installation of other modules, that I suddenly noticed problems that had other reasons?

As soon as I've opportunity this week I will have another try on a drupal test installation. I will report my experiences then.

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Closed (fixed)