On Fri, Sep 11, 2015 at 9:29 AM, Morgan Fainberg <morgan.fainb...@gmail.com> wrote:
> 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. > > +1 > 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 > >
__________________________________________________________________________ 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
