Last Comment Bug 483987 - Administrators can't create user accounts when using the Env authentication method
: Administrators can't create user accounts when using the Env authentication m...
Status: RESOLVED FIXED
:
Product: Bugzilla
Classification: Server Software
Component: Administration (show other bugs)
: 3.2.2
: All All
: -- major (vote)
: Bugzilla 3.4
Assigned To: Frédéric Buclin
: default-qa
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-18 06:46 PDT by Dimitri
Modified: 2010-02-28 10:43 PST (History)
5 users (show)
mkanat: approval+
mkanat: approval3.4+
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch, v1 (997 bytes, patch)
2009-12-29 11:32 PST, Frédéric Buclin
mkanat: review+
Details | Diff | Review

Description Dimitri 2009-03-18 06:46:30 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.0.7) 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.
Comment 1 Frédéric Buclin 2009-03-18 07:00:10 PDT
dupe of bug 478748?
Comment 2 Dimitri 2009-03-18 07:40:18 PDT
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.
Comment 3 Eric Olson 2009-07-09 12:36:33 PDT
Also a possible dupe of bug 478749.
Comment 4 Michael Thomas (Mockodin) 2009-07-09 13:56:40 PDT
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.
Comment 5 Frédéric Buclin 2009-12-29 11:00:53 PST
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.
Comment 6 Frédéric Buclin 2009-12-29 11:32:55 PST
Created attachment 419441 [details] [diff] [review]
patch, v1

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.
Comment 7 Max Kanat-Alexander 2009-12-29 17:34:59 PST
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.
Comment 8 Max Kanat-Alexander 2009-12-29 17:35:30 PST
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.)
Comment 9 Frédéric Buclin 2009-12-29 17:43:13 PST
(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.
Comment 10 Frédéric Buclin 2009-12-29 17:44:26 PST
(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. ;)
Comment 11 Max Kanat-Alexander 2009-12-29 18:15:01 PST
(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.
Comment 12 Frédéric Buclin 2009-12-29 18:18:05 PST
(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.
Comment 13 Frédéric Buclin 2009-12-30 06:31:50 PST
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: 1.153.2.1; previous revision: 1.153
done

Note You need to log in before you can comment on or make changes to this bug.