[openstack-dev] [Keystone] v3 auth_token and version
Henry Nash
henryn at linux.vnet.ibm.com
Thu Mar 21 17:16:35 UTC 2013
So agree with Dolph's comment - and what you'll find is that a domain qualifier will be included when you need it, for example:
X_USER_DOMAIN_ID
will be present in a v3 token because you made need it to qualify which domain a user is in to correctly identify them. In v2 token you know the user name is unique by definition. So if there is no X_USER_DOMAIN_ID defined in the token, then you know you can use user name on its own safely.
See the doc info at the top of auth_token if keystoneclient/middleware for a more details description.
Henry
On 21 Mar 2013, at 16:17, Dolph Mathews wrote:
> X_TENANT_ID should be deprecated in favor of X_PROJECT_ID, and the values should be equivalent. The same applies to *_NAME.
>
> I'm curious what the use case is for detecting which API is in use? If you need to distinguish between them, then we probably did something wrong!
>
> -Dolph
>
>
> On Tue, Mar 12, 2013 at 3:39 AM, Chmouel Boudjnah <chmouel at chmouel.com> wrote:
> Hi,
>
> I see that this review has been merged:
>
> https://review.openstack.org/#/c/23401/
>
> and while thinking about the integration with (swift middleware)
> keystoneauth I was wondering what would be the best way for a
> middleware that goes after auth_token to detect which version of
> keystone API we are authing.
>
> We can always check for X_PROJECT/TENANT variable to know what
> keystone server version auth_token was authenticating to but what
> about instead a X_AUTH_VERSION there to make it easier ?
>
>
> Chmouel.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130321/006faa11/attachment.html>
More information about the OpenStack-dev
mailing list