Closed (fixed)
Project:
Drupal core
Version:
4.7.0-beta1
Component:
user.module
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
15 Dec 2005 at 21:45 UTC
Updated:
15 Feb 2006 at 13:31 UTC
Jump to comment: Most recent file
Comments
Comment #1
Bèr Kessels commentedI can confirm the bug.
Comment #2
Bèr Kessels commentedA heads up.
Line ~1200 user.module in _user_edit_validate states:
Obviously on registration, a user has no rights yet. So user_access('change own username') || user_access('administer users') always FALSE.
A quick solution would be to add a third item to the if,
But that is no *real* solution. The problem lies in the very badly coded op-in security. WE validate only if Foo or bar are treu. We *should* *always* validate. And optionally skip validation if, and only if certain settings explicitly tell us to. Opt-out security.
Comment #3
Bèr Kessels commentedHere is a patch that fixes this using abovementioned solution. Note that, however this fixes this, by no means I think this is the route to take. The problem, as stated above, lies deeper.
Comment #4
Bèr Kessels commentedComment #5
merlinofchaos commentedI'm not completely sure, but wouldn't it be better to check if the $user record has no uid? In that case, the name *always* needs validation because we know that if there is no uid, it's not already in the database.
Comment #6
Bèr Kessels commented@merlin. That would be a step closer to tighter secure programming. But I would say turning around the loc and rewriting that validate function completely is the best solution:
* always return TRUE, so always return an error, or non validating part.
* If there is a uid, then do specific checking for an existing account
* else (default) check for validated email addies, blocked users, and names.
Ber
Comment #7
Bèr Kessels commentedThe patch I supplied breaks the edit-user fields.
Comment #8
killes@www.drop.org commentedThis is fixed.
Comment #9
killes@www.drop.org commentedThis is fixed.
Comment #10
(not verified) commented