SPEC incorrect about return from POST /tokens

Bug #843183 reported by klmitch
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
High
Unassigned

Bug Description

Page 22 of the spec indicates that the return from a successfully authenticated call to POST /tokens will be:

    "auth" : {
        "token" : {
            "id" : "asdasdasd-adsasdads-asdasdasd-adsadsasd",
            "expires" : "2010-11-01T03:32:15-05:00"
        },
        "serviceCatalog" : {
            "service1" : [...]
    }

In reality, this is not correct. The actual JSON returned from a call to GET/POST/PUT/DELETE /tokens is similar to the following:

            "auth": {
                "token": {
                    "expires": "2010-11-01T03:32:15.123456",
                    "id": "999888777666",
                    "tenantId": "1234",
                    "user": {
                        "username": "test_user",
                        "tenantId": "1234"
                    }
                }
            }

Note that the attributes returned is different, and the datetime format is not correct.

Revision history for this message
klmitch (q-noreply) wrote :

Fixed data returned for token. serviceCatalog is being implemented by Yogi. Coming soon...

Revision history for this message
klmitch (q-noreply) wrote :

coolio. thx, Z.

Revision history for this message
klmitch (q-noreply) wrote :

Dooh, we was (incorrectly?) using this data in our work of making keystone/extensions work from the openstack api

    https://github.com/cloudbuilders/openstack.api/blob/master/openstack/auth/tokens.py
    https://github.com/cloudbuilders/openstack.api/blob/master/openstack/auth/__init__.py

Key error 'user' in

    return self._info['user']['username']

This data needs return on the validation of tokens correct? Is it still being returned? (maybe we are hitting the wrong endpoint?)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.