We don't utilize email address for anything. It is not meant to be a top-level column. We've had a lot of discussions on this. The main result is we decided that Keystone should be getting out of the PII game as much as possible.
I am against making email a top level attribute. Instead we should be de-emphasizing adding in email (for PII reasons, as keystone does not have a way to securely store them - even as a top-level column) unless email is used as a username. As I recall "email address" was meant to be removed from most/all of our API examples for these reasons. Unless OpenStack or Keystone starts making real use of the email address and needs that PII in the keystone store, it doesn't make sense to treat it as a first class attribute. Keystone is not a CRM tool. As a side note, I have proposed a way (it needs further work and would be a Mitaka target) to add validation to the extra attributes on a case-by-case basis for a given deployment. [1] [1] https://review.openstack.org/#/c/190532/ Sent via mobile > On Sep 11, 2015, at 06:55, Lance Bragstad <lbrags...@gmail.com> wrote: > > > >> On Fri, Sep 11, 2015 at 8:04 AM, David Stanek <dsta...@dstanek.com> wrote: >>> On Fri, Sep 11, 2015 at 8:26 AM, Christian Berendt <christ...@berendt.io> >>> wrote: >>> At the moment it is possible to create new users with invalid mail >>> addresses. I pasted the output of my test at >>> http://paste.openstack.org/show/456642/. (the listing of invalid mail >>> addresses is available at >>> http://codefool.tumblr.com/post/15288874550/list-of-valid-and-invalid-email-addresses). >>> >>> Is it intended that addresses are not be validated? >>> >>> Does it makes sense to validate addresses (e.g. with >>> https://github.com/mailgun/flanker)? >> >> >> I don't know the complete history of this (I'm sure others can chime in >> later), but since Keystone doesn't use the email address for anything it was >> never really considered a first class attribute. It is just something we >> accept and return through the API. It doesn't even have its own column in >> the database. > > Correct, I believe this is the reason why we don't actually tie the email > address attribute validation into jsonschema [0]. The email address attribute > is just something that is grouped into the 'extra' attributes of a create > user request, so it's treated similarly with jsonschema [1]. I remember > having a few discussions around this with various people, probably in code > review somewhere [2]. > > I think jsonschema has built-in support that would allow us to validate email > addresses [3]. I think that would plug in pretty naturally to what's already > in keystone. > > [0] > https://github.com/openstack/keystone/blob/aa8dc5c9c529c2678933c9b211b4640600e55e3a/keystone/identity/schema.py#L24-L33 > [1] > https://github.com/openstack/keystone/blob/aa8dc5c9c529c2678933c9b211b4640600e55e3a/keystone/identity/schema.py#L39 > > [2] https://review.openstack.org/#/c/132122/6/keystone/identity/schema.py > [3] > http://python-jsonschema.readthedocs.org/en/latest/validate/#validating-formats > > >> >> I don't like this for a variety of reasons and we do have a bug[1] for >> fixing this. Last Thursday several of us were discussing making a database >> column for the email address as part of the fix for that bug. >> >> 1. https://bugs.launchpad.net/keystone/+bug/1218682 >> >> -- >> David >> blog: http://www.traceback.org >> twitter: http://twitter.com/dstanek >> www: http://dstanek.com >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
