User's email format hasn't been checked

[Haiwei Xu]

When a user is created, the email attribute can be in any format.
I think it's necessary to do the format check of email.

$ keystone user-list
+----------------------------------+----------------+---------+-----------------------+
| id | name | enabled | email |
+----------------------------------+----------------+---------+-----------------------+
| 4d0458857e604f0e9ceeefdea61f92a2 | testuser | True | test_user@@ |

[Dolph Mathews (dolph)]

This sounds like a good candidate for a wishlist item against oslo, as similar work for 'name' validation has been proposed there... and it would definitely be painful to have conflicting 'email' validation algorithms floating around openstack (it's a surprisingly difficult problem to validate email addresses).

'email' is a non-spec attribute in the v3 identity API so I'm not 100% sure it makes sense to add keystone or do verification on the server side.

[Haiwei Xu (xu-haiwei)]

Hi Dolph,

It seems jsonschema will be used to keystone, and I found there were email format validation in it. What about using jsonschema after it is imported to keystone. Before that we can just use the regular expression like "^[A-Za-z0-9][A-Za-z0-9\.]*@([A-Za-z0-9]+\.)+[A-Za-z0-9]+$".

On the other hand I think it's necessary to add the check in both server and the client sides. What do you think?

[Dolph Mathews (dolph)]

As I mentioned above, it's a non-spec attribute, so there's no guarantee that an email will be provided.

If you want to pursue it on the server-side, the fix would go in the create_user() and update_user() methods of the identity Manager class.

[Dolph Mathews (dolph)]

Regarding the regular expression, it failed on the second valid email address I gave it (<email address hidden>). If jsonschema is sufficiently capable, go ahead and use that. jsonschema is already required via global requirements [1] as:

  jsonschema>=1.3.0,!=1.4.0

[1]: https://github.com/openstack/requirements/blob/master/global-requirements.txt

[Dolph Mathews (dolph)]

You can find several examples to test email validation algorithms against on wikipedia:

  http://en.wikipedia.org/wiki/Email_address#Examples

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/46041

[Haiwei Xu (xu-haiwei)]

Hi Dolph,

I have added the validation by using the jsonschema though jsonschema does not satisfy all the examples in the wikipedia you suggested. IMO it's not bad to use jsonschema since it is provided in keystone.

[Rodrigo Duarte (rodrigodsousa)]

Hi,

Joining the discussion.

After doing some research, maybe a better idea is just to check points and @ using "/.+@.+\..+/i", since jsonschema just checks if the provided string contains @, doesn't make sense to import the whole library (as pointed by the comments in the patch).

What do you think?

[Lance Bragstad (lbragstad)]

I have a patch up in Keystone that will help with this if you're still going for the jsonschema route.

https://review.openstack.org/#/c/86483/23/keystone/common/validation/parameter_types.py

I am working on implementing validation on the Keystone APIs as I go, and I haven't gotten to the Identity API yet. Actually implementing this on the Identity API would look similar to:

https://review.openstack.org/#/c/86484/

For more information, I've detailed this work in a keystone-spec:

https://github.com/openstack/keystone-specs/blob/master/specs/juno/keystone-api-validation.rst

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/132122

[David Stanek (dstanek)]

Unassigned due to lack of activity.

[Steve Martinelli (stevemar)]

marked this as invalid for keystoneclient since the server should respond with validation.

this can be completed by extending the current json schema for user create and update: https://github.com/openstack/keystone/blob/master/keystone/identity/schema.py#L24-L33

this should be for V3 only.

[Henry Nash (henry-nash)]

I agree with the concern that since email is not a supported attribute (for storage) in the server (we had that debate), it would seem strange to add code in the server for validation. Seems to me there are two scenarios:

1) If it is being stored in Keystone as an extra, then keystone shouldn't know or care about the format - the client has to do this
2) If the user entities are backed by LDAP, then Keystone is just a pass through - and the LDAP store should reject invalid email entries (assuming you are operating R/W mode).

[Steve Martinelli (stevemar)]

We can enforce this at the client level then, openstackclient would be a nice spot to improve

[Morgan Fainberg (mdrnstm)]

UNless email becomes a top-level attribute this is not something we will validate. Validate in the client or make it a top-level attribute.