[openstack-dev] Moving auth_token middleware dependencies to openstack common

Joseph Heck heckj at mac.com
Tue Sep 11 17:21:06 UTC 2012


Not sure I understand your question Dolph - isn't CMS one of the pieces that he's suggesting?

I think moving this into openstack-common would make good sense - the big request that's driving this (aside from general cleanliness) is the request to not have to install all of keystone to get the auth_token bits.

The best way we can help with that is to make sure we have the dependencies well encapsulated around auth_token and share that info with the packagers (which I think reasonably means making some dev-docs notes about it - although we could of course just pop in and pester #openstack-packaging).

-joe

On Sep 11, 2012, at 10:05 AM, Dolph Mathews <dolph.mathews at gmail.com> wrote:
> Would it be appropriate to formally move cms into openstack-common as well? It seems clients should eventually consume some of that functionality as well (e.g. verify_token)?
> 
> -Dolph
> 
> 
> On Tue, Sep 11, 2012 at 11:20 AM, Adam Young <ayoung at redhat.com> wrote:
> I think that we can get away with the current set up for auth_token middleware  (shipping it inside Keystone but deploying it as a stand alone file) if we move its dependencies to openstack common.  Those dependencies are:
> 
> keystone/common/cms.py
> keystone/common/utils.py
> 
> cms Is all my work, and I am happy to change it to openstack commons pulled in as a dependency.
> 
> keystone/common/utils.py has one function in it that is used by auth_token:
> 
> utils.hash_signed_token(signed_text)
> 
> Which is a very thin wrapper around hashlib:
> 
> def hash_signed_token(signed_text):
>     hash_ = hashlib.md5()
>     hash_.update(signed_text)
>     return hash_.hexdigest()
> 
> We can move this to the auth_token middleware, as the only other place it is used is in the unit test code in keystone tests/test_auth_token_middleware.py
> 
> This will add a hashlib dependency on auth_token middleware,  but it is required for Signed token authentication anyway.
> 
> The risk here is that changes to fix issues in Keystone that originate with PKI/CMS handling will require changes to both Common and Keystone projects in sync,  but if I get an agreement from the common folk  that they will be responsive to Keystone changes, that should not be a real problem.
> 
> 
> Is this acceptable?
> 
> _______________________________________________
> 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/20120911/58a7abb7/attachment.html>


More information about the OpenStack-dev mailing list