yahoo-eng-team team mailing list archive

[Adam Gandelman <1411478@xxxxxxxxxxxxxxxxxx>]

** Changed in: keystone/juno
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1411478

Title:
  Any attribute that is equal to 'TRUE' or 'FALSE' is treated as boolean
  by LDAP drivers

Status in OpenStack Identity (Keystone):
  Fix Released
Status in Keystone juno series:
  Fix Released

Bug description:
  Our core LDAP driver makes a dangerous assumption that any attribute
  that is equal to the string 'TRUE' or 'FALSE' must be a boolean and
  will covert the value accordingly.  For instance the following test:

      def test_hn1(self):
          ref = {
              'name': 'TRUE',
              'domain_id': CONF.identity.default_domain_id}
          ref = self.identity_api.create_user(ref)
          ref1 = self.identity_api.get_user(ref['id'])
          self.assertEqual(ref ,ref1)

  will fail (on an LDAP backend) with:

  MismatchError: !=:
  reference = {'domain_id': 'default',  'enabled': True,  'id': 'd4202d8717104d2bb2ab49fec5e7fe70',  'name': 'TRUE'}
  actual    = {'domain_id': 'default',  'enabled': True, 'id': u'd4202d8717104d2bb2ab49fec5e7fe70',  'name': True}

  Ouch!

  Now that we have a schema for our models, perhaps we should use that
  to determine whether something is a boolean or not? e.g. for projects,
  we have:

  _project_properties = {
      'description': validation.nullable(parameter_types.description),
      # NOTE(lbragstad): domain_id isn't nullable according to some backends.
      # The identity-api should be updated to be consistent with the
      # implementation.
      'domain_id': parameter_types.id_string,
      'enabled': parameter_types.boolean,
      'parent_id': validation.nullable(parameter_types.id_string),
      'name': {
          'type': 'string',
          'minLength': 1,
          'maxLength': 64
      }
  }

  For some reason the user/group ones don't exist yet, but we can fix
  that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1411478/+subscriptions