Closed Bug 236560 Opened 20 years ago Closed 20 years ago

change a login n@domain to <n@domain> removes link in 'Select user'

Categories

(Bugzilla :: User Accounts, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 2.16

People

(Reporter: aka, Assigned: goobix)

References

()

Details

(Whiteboard: [fixed in 2.16.6] [fixed in 2.18rc1])

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821

Bugzilla 2.17.7: I selected a login and renamed it from n@domain to <n@domain>.
After 'update' and http://ssv.coware.de/bugzilla/editusers.cgi with an empty
match string the user is listed in 'Select user' with its 'Real name' but there
is no link in 'Edit user...'. A second try results in: Updated user\nSorry, user
name '' is already in use.

Reproducible: Couldn't Reproduce
Steps to Reproduce:
1.rename login from n@domain to <n@domain>
2.update
3.Edit more users
4.Select all users
5.The one renamed is listed as first but without any link to edit



Expected Results:  
Allow to edit the user data.
What version of Bugzilla are you using?

Have you changed your emailregexp to allow < and > characters?  In theory it
shouldn't allow those in email addresses.

If it's allowing them, that's an XSS hole waiting to happen.

Due to the XSS implications, securing bug until we figure out what's going on.
Group: webtools-security
OS: Linux → All
Hardware: PC → All
We don't validate new email addresses entered from the management side. This may
be by design - admins want to set it to something invalid. But we also don't
escape them when printing them in editusers.cgi.

editusers.cgi:359.

Gerv
> What version of Bugzilla are you using?
2.17.7

> Have you changed your emailregexp to allow < and > characters?  In theory it
> shouldn't allow those in email addresses.
No, I did standard installation.Change was done from admin.

I assume that my strange name change resulted in a zero-length user name. 
The installation was new, the user hidden had no related data in database. For
me I solved the problem by temporarily allowing to delete the user -- anyway it
should be possible to have a link to edit preferences.

I ran into that due to following error message of the 'sanity check': 'Bad
profile email address, id=1, <aka@aka.coware.de>.'
guess we need to sanitycheck the admin entry, too, that's probably the best
short-term fix for this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking2.18+
Flags: blocking2.16.6+
Target Milestone: --- → Bugzilla 2.16
Blocks: 206037
Attached patch Patch v1Splinter Review
<justdave> [...] should be a quick fix...  need to html_quote email addresses
in editusers.cgi and ensure emails entered on the edit/create user form match
the emailregexp

The "create user screen" already validates the entry data againest the regexp,
but the rest of the points remain valid.
Assignee: myk → vladd
Status: NEW → ASSIGNED
Attachment #152369 - Flags: review?
Comment on attachment 152369 [details] [diff] [review]
Patch v1

r=joel
when we get arund to templatizing this, we should make better error messages as
well.
Attachment #152369 - Flags: review? → review+
Comment on attachment 152369 [details] [diff] [review]
Patch v1

r=justdave for trunk.

This does not apply cleanly to 2.16, we'll need a separate patch for 2.16.
Whiteboard: [wanted for 2.16.6] [ready for 2.18rc1]
Attachment #152423 - Flags: review?
Flags: approval?
Flags: approval2.16?
Attachment #152423 - Flags: review?(bugreport)
Comment on attachment 152423 [details] [diff] [review]
Patch for 2-16 BRANCH

r=joel if you've tested it
Attachment #152423 - Flags: review?(bugreport) → review+
Attachment #152423 - Flags: review?
Whiteboard: [wanted for 2.16.6] [ready for 2.18rc1] → [ready for 2.16.6] [ready for 2.18rc1]
Flags: approval2.16? → approval2.16+
Flags: approval? → approval+
checked in on both branches
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Whiteboard: [ready for 2.16.6] [ready for 2.18rc1] → [fixed in 2.16.6] [fixed in 2.18rc1]
Clearing the security flag on disclosed bugs
Group: webtools-security
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: