Protect "Request New Password" as well [#680608]

Currently it is possible for users who's password is protected to request a new password, which will reset their password.

I've attached a patch for the 6.14 that does the following things:

- Added code to (optionally) validate the user_pass ("Request New Password") form. If the user is question is protected form editing their password, then the request is rejected, and the user sees an error message directing them to contact the administrator.

- Added a "Configration" tab that currently only contains two items: a checkbox to enable or disable validation of the user_pass form, and a textfield to allow the administrator to specify the URL to use when telling the user to contact the site administrator.

I see in some of the other comments that you're not adding new features in the D6 stream. Hopefully if you do release any bug fixes, you'll change your mind and include this. If there are things you'd like to change about it before including it, let me know - I'm happy to spend a bit more time tweaking it. As for D7, I'm not sure how helpful this will be, but I'd love to see this feature in D7 also.

Thanks for a great module!

Comment	File	Size	Author
#6	userprotect.2nd.patch	1.5 KB	asacamano
#6
	userprotect.patch	7.88 KB	asacamano

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

hunmonk CreditAttribution: hunmonk commented 11 January 2010 at 18:35

this patch is way overkill IMO. i would accept a much simpler version that simply blocked a user from being able to access the 'user/password' path if they don't have the 'change own password' permission.

Comment #2

hunmonk CreditAttribution: hunmonk commented 11 January 2010 at 18:36

Status:

Active

» Needs work

Comment #3

asacamano CreditAttribution: asacamano commented 12 January 2010 at 16:13

Thanks for the feedback. Unless I'm missing something, I don't think that would work: the user isn't logged in when they access user/password, so we can't check for the 'change own password' permission. Am I missing something simple, though?

Comment #4

asacamano CreditAttribution: asacamano commented 12 January 2010 at 16:15

Oh course, the patch could be a lot simpler without the checkbox and the setting tab. I just didn't want to make everyone else take that functionality. But if it seems like a good idea to you - then I would be happy to just make it the default behavior when the password is protected, and yank the tab and configuration.

Comment #5

hunmonk CreditAttribution: hunmonk commented 12 January 2010 at 19:45

yes, you're right in #3. my logic requires a small adjustment ;)

not too much though. you would let them hit the password form, and hook_form_alter() in a validation function -- from there you should be able to load their user account, inspect their permissions, and return drupal_access_denied() as appropriate.

yes, it should be the default behavior when the password is protected via the absence of the 'change own password' permission. we already specifically know that the user shouldn't be able to edit their own password -- it's sensible to think that they shouldn't be able to, well, edit it by requesting a new one... ;)

Comment #6

asacamano CreditAttribution: asacamano commented 13 January 2010 at 11:40

File	Size
userprotect.2nd.patch	1.5 KB

Sounds good. Here's a revised patch with all of the extra junk removed.

Comment #7

hunmonk CreditAttribution: hunmonk commented 13 January 2010 at 14:23

we're getting there. couple of things:

a) drupal coding standard for indentation is two spaces -- looks like there are some tabs in there.
b) forgot to mention this before, but we'll need this same patch rolled for the 7.x branch.

i think once those two things are done, plus a quick functionality test on my end, we can get this committed.