I remain puzzled on how to administer user accounts in drupal (6). Any changes to an account, such as activating or blocking an account, requires knowledge of the accounts password. I don't know their passwords. This is the case even for user 1. How is this usually handled?
You don't need to know the account password, just leave it blank. Those fields are used only when you need to update the account password.
On Mar 20, 2010, at 11:58 AM, Scott wrote:
I remain puzzled on how to administer user accounts in drupal (6). Any changes to an account, such as activating or blocking an account, requires knowledge of the accounts password. I don't know their passwords. This is the case even for user 1. How is this usually handled?
-- [ Drupal support list | http://lists.drupal.org/ ]
I'm getting an error when I try to ignore the password fields. The confirm password field is blank and the message I get is that the passwords don't match. Therefore the user record is not updated.
On Sat, 2010-03-20 at 12:08 -0700, Paul Kim wrote:
You don't need to know the account password, just leave it blank. Those fields are used only when you need to update the account password.
On Mar 20, 2010, at 11:58 AM, Scott wrote:
I remain puzzled on how to administer user accounts in drupal (6). Any changes to an account, such as activating or blocking an account, requires knowledge of the accounts password. I don't know their passwords. This is the case even for user 1. How is this usually handled?
-- [ Drupal support list | http://lists.drupal.org/ ]
On 3/20/2010 3:58 PM, Scott wrote:
I'm getting an error when I try to ignore the password fields. The confirm password field is blank and the message I get is that the passwords don't match. Therefore the user record is not updated.
it's possible that if you have stored your own log-in password in your browser, that your browser is auto-filling the Password field wtih _your_ password. When making changes to another user's account, make sure *both* password fields are blank, unless you are in there to reset their password (in which case you will need to replace the contents of the Password field with _their_ password and then retype it in the Confirm Password field).
make sense?
kazar
I just tested this and it does seem to be the case. I tried blocking a test user by clearing the value in the password field and setting the blocked toggle while monitoring the encrypted password value in _users using mysql. The user record was saved correctly and the encrypted password string remained the same. I should have suspected this. Thanks.
On Sat, 2010-03-20 at 17:05 -0400, Adept wrote:
On 3/20/2010 3:58 PM, Scott wrote:
I'm getting an error when I try to ignore the password fields. The confirm password field is blank and the message I get is that the passwords don't match. Therefore the user record is not updated.
it's possible that if you have stored your own log-in password in your browser, that your browser is auto-filling the Password field wtih _your_ password. When making changes to another user's account, make sure *both* password fields are blank, unless you are in there to reset their password (in which case you will need to replace the contents of the Password field with _their_ password and then retype it in the Confirm Password field).
make sense?
kazar
I've just had a three month baptism of open registration and user administration.
Registrations are driven by "backlinkers" in pursuit of page rank. Some registrants will comment or post with backlinks as well as pimping their sites in profiles.
Moderation is a must to prevent embarrassing content leaking to a sensitive audience. The burden of moderation can be mitigated by spam suppression like mollom and recaptcha.
Initially I "blocked" errant registrants but the profiles persist which is the primary goal of the backlinkers. I have since opted to "delete" rather than block. Advuser helps, "prune" is too crude.
In the medium run, I am honing an SQL query to separate the sheep from the goats preserving valued registrants meaning those who post relevant content. Hopefully that will lead to a "purge" module that can be "cron"-ed.
Jim
On Sun, Mar 21, 2010 at 10:34 AM, Scott scott@bscottholmes.com wrote:
I just tested this and it does seem to be the case. I tried blocking a test user by clearing the value in the password field and setting the blocked toggle while monitoring the encrypted password value in _users using mysql. The user record was saved correctly and the encrypted password string remained the same. I should have suspected this. Thanks.
On Sat, 2010-03-20 at 17:05 -0400, Adept wrote:
On 3/20/2010 3:58 PM, Scott wrote:
I'm getting an error when I try to ignore the password fields. The confirm password field is blank and the message I get is that the passwords don't match. Therefore the user record is not updated.
it's possible that if you have stored your own log-in password in your browser, that your browser is auto-filling the Password field wtih _your_ password. When making changes to another user's account, make sure *both* password fields are blank, unless you are in there to reset their password (in which case you will need to replace the contents of the Password field with _their_ password and then retype it in the Confirm Password field).
make sense?
kazar
-- [ Drupal support list | http://lists.drupal.org/ ]
-
Adept -
Jim Tarvid -
Paul Kim -
Scott