Can edit user name, email to illegal values

[Rani Fields]

Under Identity > Users, you can edit usernames and emails to illegal values (string too long, invalid characters/format, etc). The test string for both email and username update is "abcdefghijklmnopqrstuvwxyz!@#$%^&*()_+1234567890-=[]\{}|;':",./<>? baduser2".

This behavior is not in line with user creation's validation. When you attempt to create a user with the test string as a username or email, you get an error. This validation present during user creation does not appear to be active when editing the user's name or email.

Furthermore, when you set the user's name to the test string, you will be unable to log on using that username due to a name length issue. The test string's length is 75 characters; the horizon log-on maximum is 64.

[Itxaka Serrano (itxaka)]

Hello,

I cant reproduce the email part (I get a validator error) but I can the user name.

Still, why do you think that test string should be invalid? The user is created like that in keystone so it should not be an issue that you can use those characters for a user name.

+-------------+-----------------------------------------------------------------------------+
| Property | Value |
+-------------+-----------------------------------------------------------------------------+
| description | |
| enabled | True |
| id | 331158438bfe4ab6a71b961e6909b026 |
| name | abcdefghijklmnopqrstuvwxyz!@#$%^&*()_+1234567890-=[]\{}|;':",./<>? baduser2 |
| tenantId | 250ccf4b33c24afe918d5fd3bcc2ca41 |
| username | abcdefghijklmnopqrstuvwxyz!@#$%^&*()_+1234567890-=[]\{}|;':",./<>? baduser2 |
+-------------+-----------------------------------------------------------------------------+

Now, the issue with the login is true, the max char should not be limited to 64.

[Itxaka Serrano (itxaka)]

Actually I just tried and could login with that username with no problems, no character limit.

Can you explain the actual steps to reproduce this and the version used?

[Mitali Parthasarathy (mnparthasarathy)]

The issue is seen in Kilo. It doesn't happen when you create a new user/email or change the username. Appropriate errors are thrown in these cases. It happens only when you try to edit an existing email to something which is not in email format.

[Mitali Parthasarathy (mnparthasarathy)]

To add to the above comment: You should try to update the email by clicking the 'pen' image on the table row (see attached image). Editing using the 'Edit' button works fine. I would just make these fields uneditable if the checks can't be performed while changing them. User can still edit using the Edit form which does the correct checks.

[David Cusatis (dcusati)]

I can't seem to fully reproduce this, or maybe I'm misunderstanding how to do so. I was able to set my username to the test string you provided, but the email does not let the user save it, and is highlighted red.

[Richard Jones (r1chardj0n3s)]

Verified that inline edit through the pencil icon in the table can be used to set the username to an invalid value.

[Chason Chan (chen-xing)]

It is OK in my enviroment, I don't know why.

[Akanksha Agrawal (akanksha-aha)]

I tried reproducing the bug. Did not face any issue with either name or email. I tried using the test string in the bug description as the username and I still could login successfully. I don't think this bug is still valid.

[mukund (mukund-gandlur)]

I have tried reproducing this bug with the string below as email id and the Id got created.
"!!!!!!*&_^%#+_-///'qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq!!!!!!@asaljdfhasjdhl.com". This bug is valid.

[sandeep nandal (nandal)]

User can be created or edited with "abcdefghijklmnopqrstuvwxyz!@#$%^&*()_+1234567890-=[]\{}|;':",./<>? baduser2" invalid string in horizon on Mitaka Release. Therefore, the bug is confirmed.

Hi Aakash,

I don't see any update on this from your end since Feb 16, Kindly confirm if you are still working on this.
If not, then I can work on it.

[sandeep nandal (nandal)]

# openstack user create "abcdefghijklmnopqrstuvwxyz@#$%^&*()_+123 4567890-=[]\{}|:,./<>? baduser2" --password-prompt
User Password:
Repeat User Password:
+----------+--------------------------------------------------------------------------+
| Field | Value |
+----------+--------------------------------------------------------------------------+
| email | None |
| enabled | True |
| id | bc8ba161a852445388334aaf969e9845 |
| name | abcdefghijklmnopqrstuvwxyz@#$%^&*()_+123 4567890-=[]\{}|:,./<>? baduser2 |
| username | abcdefghijklmnopqrstuvwxyz@#$%^&*()_+123 4567890-=[]\{}|:,./<>? baduser2 |
+----------+--------------------------------------------------------------------------+

[Steve Martinelli (stevemar)]

For keystone, this should be fine in v3. We check email and name with jsonschema. It is likely the original bug is using our v2.0 API which does not have schema validation. Including schema validation in v2.0 calls is part of a larger blueprint: https://blueprints.launchpad.net/keystone/+spec/schema-validation-extent

[Steve Martinelli (stevemar)]

Refer to https://review.openstack.org/#/c/345022/ for the keystone fix, which should fix things in OSC

[surbhi sarda (surbhisarda)]

@Aakash Soni can i work on this bug??

[Vladislav Kuzmin (vkuzmin-u)]

I've checked this bug one more time and I think that this bug is not actual.
1) I tried to create and edit user after creation with name like in original description -- "abcdefghijklmnopqrstuvwxyz!@#$%^&*()_+1234567890-=[]\{}|;':",./<>? baduser2" and I did not encounter any problems with a length of 64 characters. I still can log in. Nobody in this thread can’t explain why this string is invalid.
2)As described in comment #9 here email "!!!!!!*&_^%#+_-///'qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq!!!!!!@asaljdfhasjdhl.com" is valid because these characters are allowed in email address. Characters that can be used for an email address are well described here -- https://stackoverflow.com/a/2049510 Invalid email is "<email address hidden>" and it doesn't allowed in Horizon as you can see in attachment.
I think this bug is invalid.