keystoneclient token-get should work with --token/SERVICE_TOKEN

Bug #1002917 reported by Dolph Mathews
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)

Bug Description

Currently, running token-get fails because a service catalog isn't retrieved by the client:

    $ keystone --token=ADMIN --endpoint=http://localhost:35357/v2.0/ token-get
    'Client' object has no attribute 'service_catalog'

While I think token-get should attempt to validate the specified token, it should at least echo it back instead of spewing an error message, e.g.:

    $ keystone --token=ADMIN --endpoint=http://localhost:35357/v2.0/ token-get
    | Property | Value |
    | id | ADMIN |

Changed in keystone:
status: New → In Progress
Dolph Mathews (dolph)
Changed in keystone:
status: In Progress → Confirmed
assignee: Dolph Mathews (dolph) → nobody
Revision history for this message
Bhuvan Arumugam (bhuvan) wrote :

I think, it's because the client is authenticated only if endpoint is not specified. If endpoint is specified, it's not authenticated and in turn service_catalog is not set.

Snippet from v2_0/, line 79:

        if endpoint is None:
            self.management_url = endpoint

To get the token, I think we should authenticate explicitly using specified token and/or user/pass.

Dolph, can you please confirm?

Revision history for this message
Dolph Mathews (dolph) wrote :

Yes, but *only *in the case of token-get with a --token/SERVICE_TOKEN. Authentication or validation would both be sufficient to verify the token and ultimately print it back to the user as a known good value.

Revision history for this message
Bhuvan Arumugam (bhuvan) wrote :

Dolph, for the record I posted a patch for review.

If Username/pass or token is specified, we authenticate and print the dict {id, expires}. Otherwise, we retain default behavior.

Revision history for this message
Steve Martinelli (stevemar) wrote :

sorry dolph, as you have told me many times, the admin token itself carries no authorization. if you disagree open a bug against openstackclient to have this as a client specific feature, keystone server shouldn't change the way it's handled

Changed in keystone:
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers