Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
It can cause problems if user 1 is blocked from the site, and probably 99% of the time this is done this is an accident. This patch removes the UI for blocking user id 1. If it's desired to do this for security reasons, there's always the raw database manipulation option, which should suit advanced users without allowing newbies to totally mess up their sites.
Comment | File | Size | Author |
---|---|---|---|
#21 | prevent_user_1_lockout_2.patch | 3.24 KB | edmund.kwok |
#20 | prevent_user_1_lockout_1.patch | 3.34 KB | edmund.kwok |
#15 | prevent_user_1_lockout.patch | 3.08 KB | edmund.kwok |
#12 | patch_44.txt | 2.06 KB | webernet |
#9 | 75289_user.module_r1.685_patch_1 | 1.65 KB | AjK |
Comments
Comment #1
webernet CreditAttribution: webernet commentedMore of a feature request than a bug, plus patch no longer applies...
Comment #2
webchickEr? Patch still applies, just with an offset. But here's a re-roll anyway which will apply cleanly...
Also changing status back to bug... if nothing else, this is a UI problem. Accidentally clicking that radio button (which is possible, since clicking anywhere on the "Blocked" label will cause it to switch) while changing something else on the form will render your admin user completely useless after you log out, remediable only by editing the database if you have no other users with administer user privileges. This can't possibly be intentional behaviour that would require a feature request to change.
Comment #3
beginner CreditAttribution: beginner commentedI tested the patch. It's simple and it makes sense.
Comment #4
Steven CreditAttribution: Steven commentedYou're absolutely right. I also edited the patch to remove the ability to delete user 1.
Committed to 5 and 4.7.x.
Comment #5
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedpatch was reverted as the current way s intentional according to Dries.
Comment #6
beginner CreditAttribution: beginner commentedIf it is intentional, what is the intention?
Comment #7
Steven CreditAttribution: Steven commentedPerhaps there is a tiny use case for blocking user 1, but that does not mean that this is not a serious bug which needs to be addressed.
It is only in the case when there is at least one other user with "administer users" permissions that this action is reversible. In all other cases, it permanently screws up your Drupal site. It is also one of many useless options which are displayed when you create user account 1, so it is confusing as well. If Drupal can be hosed from the UI, it is broken.
The only thing I would see as acceptable is to add a check to see if there is another user with the permissions to unblock user 1. Otherwise, we should not show the blocking option (i.e. when creating the first account and in most other cases). However, this still does not prevent you from later deleting the user who can restore user 1 and still lock yourself out.
Deleting user 1 is certainly not desirable, as it is impossible to reverse.
Locking your Drupal site and throwing away the keys never sounds like a good idea. If you do need to maintain control, why not simply keep the password to UID 1 secret?
Comment #8
Steven CreditAttribution: Steven commentedAs an alternative for the blocking, we could make it so you can never block yourself, only others. That way you can only block user 1 if you are another user who is also priviledged.
Deleting user 1 should IMO still be completely disallowed.
Comment #9
AjK CreditAttribution: AjK commentedHere's a patch that does #8 above. Removes the delete button and the status radios when editing your own account
Comment #10
Steven CreditAttribution: Steven commentedOkay, after some discussion on #drupal, we've agreed on the following:
Comment #11
yched CreditAttribution: yched commentedSeems reasonable.
But, since the issue seems controversial (and not new, too), could you be more specific on who is "we" (in "we've agreed on the following") ?
Comment #12
webernet CreditAttribution: webernet commentedHere is a patch which (as per comment #10):
-Removes the ability to block yourself from /user/uid/edit
-Removes the ability to delete user 1 from /user/1/edit and denies access to /user/1/delete
To do:
-Remove the ability to block yourself from /admin/user/user
-Remove the ability to delete user 1 from /admin/user/user
Comment #13
webernet CreditAttribution: webernet commentedComment #14
webchickBumping this up again. Will try to take a look at those remaining issues today/tomorrow. Would be nice to get this in for this release.
Comment #15
edmund.kwok CreditAttribution: edmund.kwok commentedTook a stab at the todos in #12. Error message now displayed if user 1 is being blocked or deleted.
Comment #16
edmund.kwok CreditAttribution: edmund.kwok commentedComment #17
serval-1 CreditAttribution: serval-1 commented+1
The patch does all what is mentioned in #12.
I even tried to fiddle the hidden fields in the deletion confirmation page, without success.
A nice error message appears every time: "You cannot delete the first user account".
Comment #18
Steven CreditAttribution: Steven commentedBad code, needs to use t(). There has been some resistance to this before. But personally, I think we should not allow users to lock themselves out. I'll defer to someone else though.
Comment #19
webernet CreditAttribution: webernet commentedAs noted by Steven, message needs to be translatable.
Comment #20
edmund.kwok CreditAttribution: edmund.kwok commentedEnclosed messages with t() and removed the ability to block yourself from admin/user/user instead; Misread the todo in #12.
Comment #21
edmund.kwok CreditAttribution: edmund.kwok commentedStray x in the patch.
Comment #22
webchickLooks good to me! I tried to delete/block user 1 from user/1, from user/1/delete, and from admin/user/user, and in each case I was averted. :)
I was able to delete/block non-user 1 users fine.
Marking RTBC.
Comment #23
drummUnavailable options should only be removed for permissioning purposes. Otherwise, disabling the element is preferred. THis should be true for the user status radios.
There is no need to load $account just to get the uid which you already have.
Setting an error on a group operation makes a dead end and wasted time selecting a group. Instead, I think the offending account should be removed from the select and a message set stating what happened.
There is something like three different things going on in this patch. What about splitting this up and concentrating on one at a time?
Comment #24
drummUnavailable options should only be removed for permissioning purposes. Otherwise, disabling the element is preferred. THis should be true for the user status radios.
There is no need to load $account just to get the uid which you already have.
Setting an error on a group operation makes a dead end and wasted time selecting a group. Instead, I think the offending account should be removed from the select and a message set stating what happened.
There is something like three different things going on in this patch. What about splitting this up and concentrating on one at a time?
Comment #25
jsimonis CreditAttribution: jsimonis commentedHere's our situation...
We need to be able to block access to user/1 for other admin users. It's easy enough right now to edit user/1 and change the user name, e-mail, and password. This allows you to be able to block out access to user/1 to the person who should have access.
We're with the main parent organization. There are several "child" organizations under us. We want them to be able to do work on their site we've set up for them, but not be able to change the user/1 log-in so that it always belongs to us.
Is there a way to do this?
Comment #26
pwolanin CreditAttribution: pwolanin commentedBased on the number of forum posts by newbies who have done this, I'm tempted ot set to critical...
Comment #27
pwolanin CreditAttribution: pwolanin commentedHere a different, but creative, way to block admin account access as well: http://drupal.org/node/129299
Comment #28
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedhttp://drupal.org/project/paranoia
Comment #29
pwolanin CreditAttribution: pwolanin commentedyes, but the point is the core UI.
Comment #30
jsimonis CreditAttribution: jsimonis commentedI'd be happy even with that module, if it were updated for 5.x.
Comment #31
webernet CreditAttribution: webernet commentedThis issue recently came up in a review of Drupal posted by Dries to the development mailing list.
Related issue to disallow deletion of User 1: http://drupal.org/node/46149
Comment #32
Gábor HojtsyAnd notes in the wiki suggested:
Comment #33
Sutharsan CreditAttribution: Sutharsan commentedMoving all usability issues to Drupal - component usability.
Comment #34
Dave ReidUsers can cancel their own accounts now in D7 and there is already an existing issue to prevent deletion of uid 1 (#46149: Prevent account cancellation for uid 1). There already exist contrib modules to help with this so I think it's good to set this as won't fix.