<div dir="ltr"><br><div><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 25, 2013 at 3:45 AM, Henry Nash <span dir="ltr"><<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi<br>
<br>
Do we specify somewhere whether text field matching in the API is case sensitive or in-sensitive?  I'm thinking about filters, as well as user and domain names in authentication.  I think our current implementation will always be case sensitive for filters  (since we do that in python and do not, yet, pass the filters to the backends), while authentication will reflect the "case sensitivity or lack thereof" of the underlying database.  I believe that MySQL is case in-sensitive by default, while Postgres, sqllite and others are case-sensitive by default.  If using an LDAP backend, then I think this is case-sensitive.<br>

<br>
The above seems to be inconsistent.  It might become even more so when we pass the filters to the backend.  Given that other projects already pass filters to the backend, we may also have inter-project inconsistencies that bleed through to the user experience.  Should we make at least a recommendation that the backend should case-sensitive (you can configure MySQL to be so)?  Insist on it? Ignore it and keep things as they are?</blockquote>
<div><br></div><div>Relevant bug: <a href="https://bugs.launchpad.net/keystone/+bug/1229093">https://bugs.launchpad.net/keystone/+bug/1229093</a><br></div><div><br></div><div>I've never heard anyone complain that "keystone is case sensitive but I expect it to be case-insensitive." There is a clear expectation / assumption that we are case sensitive, and I'd like to assert that to be true in general, across driver implementations.</div>
<div><br></div><div>However, there are times when you might want to make case-insensitive comparisons, but that should be hidden from the user. For example:</div><div><br></div><div>  create_user(name='dolph', password='asdf') # should succeed</div>
<div>  create_user(name='Dolph' password='asdf') # should fail, because a case-insensitive equivalent already exists<br></div><div>  authenticate(name='Dolph', password='asdf') # should fail, because the user that exists was created with an lowercase name</div>
  get_user_by_name(name='Dolph') # should fail, because the user that exists was created with an lowercase name (until we get into case-sensitivity hints for the driver)<div><br></div><div>We don't provide for the behavior illustrated in the second line of keystone today, but I think it's worth considering (it's not trivial with UTF-8 support, though).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Henry<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div></div>