← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1669070] Re: Checking whether group has role assignment on domain without specifying a role ID result in HTTP 200

 

This isn't a bug. IF the {role_id} at the end of the call is not passed,
we use the list action of:

/v3/domains/{domain_id}/groups/{group_id}/roles/ (regardless of head or
get action)

If a role_id is passed, you're calling a different API. This is not a
great design, but this is working as intended.

** Changed in: keystone
       Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1669070

Title:
  Checking whether group has role assignment on domain without
  specifying a role ID result in HTTP 200

Status in OpenStack Identity (keystone):
  Invalid

Bug description:
  It should've been either 400 or 404. Steps to reproduce.

  1. install a vanilla devstack
  2. use "openstack group list" to find a group ID. Any group will do. i.e.

  openstack group list
  +----------------------------------+-----------+
  | ID                               | Name      |
  +----------------------------------+-----------+
  | 64e5dcd8dea0429ca22f97bcac4629bc | admins    |
  | 9ff3c6f47a034223ad19bb6d0dd52bb6 | nonadmins |
  +----------------------------------+-----------+

  3. get a token. i.e. "openstack token issue"
  4. call the check group assignment on domain API using curl without specifying the role ID and you can see an HTTP 200 is returned. i.e.

  curl -v --head -H 'X-Auth-Token: gAAAAABYtwwzxv9T3fxnHY3Js2ln2lTvoi1fukAYe0NSXgoV9S1qI808zQSYJyKb1AtTBy3MNUJFONBb7rpsIAu12zfRlZulfOgl7vvD_EM1DkMogpIRQvotJN1aYKMq8XqcgZ-NikolKCpUfas30GMQPFOoPpJdz0qjfIcniX0ihzVRTDqVcb0' http://localhost/identity/v3/domains/default/groups/64e5dcd8dea0429ca22f97bcac4629bc/roles/
  *   Trying 127.0.0.1...
  * Connected to localhost (127.0.0.1) port 80 (#0)
  > HEAD /identity/v3/domains/default/groups/64e5dcd8dea0429ca22f97bcac4629bc/roles/ HTTP/1.1
  > Host: localhost
  > User-Agent: curl/7.47.0
  > Accept: */*
  > X-Auth-Token: gAAAAABYtwwzxv9T3fxnHY3Js2ln2lTvoi1fukAYe0NSXgoV9S1qI808zQSYJyKb1AtTBy3MNUJFONBb7rpsIAu12zfRlZulfOgl7vvD_EM1DkMogpIRQvotJN1aYKMq8XqcgZ-NikolKCpUfas30GMQPFOoPpJdz0qjfIcniX0ihzVRTDqVcb0
  >
  < HTTP/1.1 200 OK
  HTTP/1.1 200 OK
  < Date: Wed, 01 Mar 2017 18:06:01 GMT
  Date: Wed, 01 Mar 2017 18:06:01 GMT
  < Server: Apache/2.4.18 (Ubuntu)
  Server: Apache/2.4.18 (Ubuntu)
  < Vary: X-Auth-Token
  Vary: X-Auth-Token
  < x-openstack-request-id: req-9ea5a135-4128-4967-8552-d1c6a7b63c97
  x-openstack-request-id: req-9ea5a135-4128-4967-8552-d1c6a7b63c97
  < Content-Length: 158
  Content-Length: 158
  < Content-Type: application/json
  Content-Type: application/json

  <
  * Connection #0 to host localhost left intact

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


References