> <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">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</span><div>
<font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">Ah, yes... I just misunderstood the above!</font></div><div><font color="#222222" face="arial, sans-serif"><br>
</font></div><div><font color="#222222" face="arial, sans-serif">+1 in favor of moving auth_token+hashing+cms to openstack-common.<br></font><div><div><br></div>-Dolph<br>
<br><br><div class="gmail_quote">On Tue, Sep 11, 2012 at 12:21 PM, Joseph Heck <span dir="ltr"><<a href="mailto:heckj@mac.com" target="_blank">heckj@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Not sure I understand your question Dolph - isn't CMS one of the pieces that he's suggesting?<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>-joe<div><div class="h5"><br><div><br></div><div><div><div>On Sep 11, 2012, at 10:05 AM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>> wrote:</div>
<blockquote type="cite">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)?<br clear="all"><div><br>
</div>-Dolph<br>
<br><br><div class="gmail_quote">On Tue, Sep 11, 2012 at 11:20 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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:<br>


<br>
keystone/common/cms.py<br>
keystone/common/utils.py<br>
<br>
cms Is all my work, and I am happy to change it to openstack commons pulled in as a dependency.<br>
<br>
keystone/common/utils.py has one function in it that is used by auth_token:<br>
<br>
utils.hash_signed_token(<u></u>signed_text)<br>
<br>
Which is a very thin wrapper around hashlib:<br>
<br>
def hash_signed_token(signed_text)<u></u>:<br>
    hash_ = hashlib.md5()<br>
    hash_.update(signed_text)<br>
    return hash_.hexdigest()<br>
<br>
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_<u></u>middleware.py<br>
<br>
This will add a hashlib dependency on auth_token middleware,  but it is required for Signed token authentication anyway.<br>
<br>
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.<br>


<br>
<br>
Is this acceptable?<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div></div></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>