User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:220.127.116.11) Gecko/2009021910 Firefox/3.0.7 (.NET CLR 3.5.30729) Build Identifier: 3.2.2 We're using apache authentication The administartor is the only one to be able to create account. In 3.2 the adduser page doesn't propose user password which is great But after clicking Add you've got the error message "password must be at least 3 characters" Reproducible: Always Steps to Reproduce: 1.env authentication 2.administartor create user 3.click add Actual Results: "password must be at least 3 characters" Expected Results: User created without password or with any non visible password as the security is handled by someone else. In the previous 2.22 branch the two edit field password and confirm password were present and entering any dummy text help you to create the accounts. which was bad but working.
dupe of bug 478748?
In user_verify_class DB is active in that case. As you must have at least one of DB/LDAP/RADIUS up for bugzilla to work. Bug 478748 is maybe close to that problem but I've no idea if it's the same.
Also a possible dupe of bug 478749.
Bug 441027 and Bug 320265 bring another issue that will effect this. Not all ENV auth systems supply an email, and it is not always possible to simply concatincate a external id and a domain suffix, eg companies with multiple domains in use. Example Web Servers w/Env Auth not supplying an Email. IIS Apache via mod_auth_pam A solution would be to create a dummy email if an email is not present and force the user to update their email properly formated one before being allowed into the system. If the instance was set to fall back on another auth method, say ldap, we could even validate the email. A similar solution could be used for this bugs reported issue. Simply set the password to be a crypthash of the login id and current time. Since it is never checked no problem.
I can reproduce the problem. So we should either 1) forbird user creation from editusers.cgi when using the 'Env' auth method (and let them be created when the user successfully authenticates against the external auth method), or 2) the password error shouldn't exist. I think it's fine to create user accounts before a user logs in for the first time, e.g. to set permissions correctly, so I'm in favour of option #2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
I set the password to '*' when not defined. If the password field is visible but left empty, the error message about a too short password is still displayed, as desired.
Assignee: administration → LpSolit
Status: NEW → ASSIGNED
Attachment #419441 - Flags: review?(mkanat)
Comment on attachment 419441 [details] [diff] [review] patch, v1 Actually, I'd like to be able to create users without passwords all the time--I frequently need to do this. So just "!$cgi->param('password')" would be better. That can be done on checkin.
Attachment #419441 - Flags: review?(mkanat) → review+
For 3.4, though, the patch should be checked in as-is. (That is, we don't want to add a new feature, just fix the bug.)
(In reply to comment #7) > (From update of attachment 419441 [details] [diff] [review]) > Actually, I'd like to be able to create users without passwords all the time--I > frequently need to do this. So just "!$cgi->param('password')" would be better. > That can be done on checkin. You can already do that with my patch. Just write * in the password field. So I prefer to use my patch as is, to make sure the password field wasn't left empty by accident.
(In reply to comment #9) > You can already do that with my patch. Just write * in the password field. Note that this already works without my patch too. ;)
(In reply to comment #10) > (In reply to comment #9) > > You can already do that with my patch. Just write * in the password field. > > Note that this already works without my patch too. ;) Yeah, it's just too cryptic and something that nobody but you and I would guess. I do that all the time currently, but I think people should just be able to create user accounts without a password. Perhaps we should add a checkbox that disables the box--something like "no password". That's something we can do in another bug, I suppose.
(In reply to comment #11) > to create user accounts without a password. Perhaps we should add a checkbox > that disables the box--something like "no password". That's something we can do > in another bug, I suppose. Yeah, the checkbox is a good idea. Disabling the input box would automatically make the password being undefined, so my patch would still work as is.
mkanat filed bug 537193 about the "no password" checkbox, so I'm committing my patch unchanged: tip: Checking in editusers.cgi; /cvsroot/mozilla/webtools/bugzilla/editusers.cgi,v <-- editusers.cgi new revision: 1.155; previous revision: 1.154 done 3.4.4: Checking in editusers.cgi; /cvsroot/mozilla/webtools/bugzilla/editusers.cgi,v <-- editusers.cgi new revision: 18.104.22.168; previous revision: 1.153 done
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Summary: Administrator can't create account when using env authentication → Administrators can't create user accounts when using the Env authentication method
You need to log in before you can comment on or make changes to this bug.