Open Stack

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 <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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/20519ef0/attachment.html>