Hi Morgan, On 16/07/2013, at 1:02 AM, Morgan Fainberg <m...@metacloud.com> wrote: > On Mon, Jul 15, 2013 at 1:06 AM, Kieran Spear <kisp...@gmail.com> wrote: > > Hi Kieran, > > I'd be happy to help you with the backporting of this fix if you need any > assistance. > > Here are some quick answers to your questions: > > 1. The individual tokens are stored in independent keys in their entirety, > since the memcache backend replaces the SQL backend. In the > usertoken-<userid> we should only be storing the hashed value. It looks like > there is a bug there (I'll check and get a fix proposed in gerrit today to > address this).
That's what it looks like. I've pushed out a one-line fix to hash the token data on our cloud and it works well. > > 2. There has been a lot of discussion on this topic and some other solutions > have been proposed (such as use a clock-mechanism to expire tokens, etc). > However, to stay compatible with the current business logic, which requires > the ability to revoke subsets of tokens for the user (instead. all tokens for > the user on every change to the user's roles/project associations, etc), a > list of current tokens for the user must be maintained. Ideally, the token > list shouldn't ever be massive, meaning the extra calls to memcache should be > limited. The general plan is to develop another approach to solve this issue > without the need of keeping a user-token-list, but it just wasn't viewed as > possible for Havana. Checking the first two tokens wouldn't exactly solve > the issue, as tokens can in theory be requested with varying expiration > times; this means that tokens in the middle of the list could be expired > whereas the tokens at the start of the list are invalid. Thanks for your work in this area. Good point on the expiry times. I'm probably guilty of premature optimisation here anyway. Will work on back porting this shortly. Kieran > > Keeping the expiry time low is definitely a good idea. > > > Let me know if you want any further details. I'd be happy to elaborate / > fill-in more. > > Cheers, > Morgan Fainberg > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
