[openstack-dev] [keystone] Case sensitivity & backend databases

Dolph Mathews dolph.mathews at gmail.com
Wed Sep 25 16:21:20 UTC 2013


On Wed, Sep 25, 2013 at 3:45 AM, Henry Nash <henryn at linux.vnet.ibm.com>wrote:

> Hi
>
> 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.
>
> 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?


Relevant bug: https://bugs.launchpad.net/keystone/+bug/1229093

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.

However, there are times when you might want to make case-insensitive
comparisons, but that should be hidden from the user. For example:

  create_user(name='dolph', password='asdf') # should succeed
  create_user(name='Dolph' password='asdf') # should fail, because a
case-insensitive equivalent already exists
  authenticate(name='Dolph', password='asdf') # should fail, because the
user that exists was created with an lowercase name
  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)

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).


> Henry
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130925/f95f60d6/attachment.html>


More information about the OpenStack-dev mailing list