[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