Recent posts
-
1 week 5 days ago
-
2 weeks 4 days ago
-
3 weeks 2 days ago
-
19 weeks 4 days ago
-
25 weeks 4 days ago
The second most important Drupal user
When you create a new Drupal installation two users are created. The first is the obvious admin user with uid 1, which you will use to create your first pieces of content (or, for larger sites, to create the moderation role, assign the necessary permissions and create the moderation users). The second user might be less obvious. It's the virtual anonymous user with uid 0. You will not find it in any user listing, you can not assign any roles to it and you can not log in as the anonymous user. It's important to realize that both users are essential.
There are many efforts being put in preventing the deletion of the admin user since you could easily delete it using the admin interface. Webchick provided a short list of support issues about users that did so and who were unable to administer their site. But surprisingly there are also many things that happen when you have no uid 0, depending on which Drupal version you're using. On Drupal 4.6 and 4.7 you receive various Duplicate entry and Access denied errors while on Drupal 5 and 6 there are issues with rebuilding the user permissions and session information is never saved. This means that any actions that require information from the $_SESSION variable will always fail because upon each page request it is completely empty.
The anonymous user doesn't disappear all by itself of course. The most obvious way is to delete the row for uid 0 from the users table. If you wonder why someone would do this, here is a real life example:
Thinking back to when we first installed Drupal, my boss and I looked at the database and sure enough we though that a user with uid set to zero and no user name and or password was a bug and probably just deleted the row. Now looking back, the bug was actually introduced by us.
The solution here is to create a new "empty" user with uid 0. You might also lose the anyonmous user when exporting and importing the users table due to the auto_increment setting, as described in this support request. If this happens, you will need to manually update the record to set the uid value back to 0.
Promote this article on various sites:
Comments
User 2
I want to know what user 2 is for...
User 2
You may hav emeant that as tongue-in-cheek, but I actually consider that almost as important as user 0. On all my sites, user 2 is me, with my real name, and minimal permissions. This allows me to login as an authenticated user to see what problems occur.
In most cases, anonymous users get nothing more than "access content." User/1, of course, doesn't even check for permissions (unless thay are assigned a specific role). So you need to know what your authenticated users will see. This is where I make myself user/2. Besides, when I want to create content with my name on it (rather than "admin") I use this log in.
In some cases, I also become user/3 for testing sub-admin permissions.
Database migration can also
Database migration can also be the culprit here. So, when you move from a test / development site to a live server, importing the SQL can cause user 0 to be deleted b/c of the auto_increment on the uid. It seems to need a positive integer value and might convert your anonymous user into an actual user. D'oh.
This problem pops up a lot in the Ubercart forums.
Exactly
That's what it says at the end of the post:
Although it's a support request for Drupal 7 I'm not sure what we can do to prevent this on a manual database import. Perhaps a check could be added on the status page to see if user 0 exists. But I believe it's mostly up to the person doing the import to check if all data is valid afterward.
drush is afected, too :-(
i just wanted to copy my db in phpmyadmin and it failed, because of user 0, do I deleted that ... and now drush doesn't bootstrap, so I am gone :-).
Post new comment