Hey Adam, Everyone,<div> Thanks for the quick response, and the link on DI. I am not really a fan of DI but, if that's the way the cool kids are going, so be it ;)</div><div><br></div><div> Realistically, all I am wondering is, how does the identity driver get at all the information from the wsgi or Driver ? Say, for example, I wanted to know/grab the openstack.context (which has the 'is_admin' flag inside it). Since it's simply a dict, I was thinking of jst passing in any values via the manager if they existed. However, that's changing the core keystone manager, only putting in the openstack.context (not all the context values for wsgi) and I assume few people would ~need~ this.</div>
<div><br></div><div> Still coming upto speed on how keystone's design works, so sorry if this doesn't make much sense ;)</div><div> Regards</div><div> S.<br><br><div class="gmail_quote">On Wed, Aug 1, 2012 at 2:18 PM, 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">Can you provide a sense of the features you are looking to implement this way?<br>
<br>
The Roles can always be requeried, although I will admit that it is sub optimal.<br>
<br>
Personally, I am not a fan of passing around the Context object the way that we do. I would much prefer an inversion of control, where each component registers its dependencies, and the context plays the middleman in handing them out.<br>
<br>
<a href="http://wiki.python.org/moin/DependencyInjectionPattern" target="_blank">http://wiki.python.org/moin/DependencyInjectionPattern</a><br>
<br>
There are some thoughts on the link:<br>
<br>
<a href="http://code.activestate.com/recipes/413268/" target="_blank">http://code.activestate.com/recipes/413268/</a><br>
<br>
<br>
For our purposes, we need to only concern ourselves with Request and GLobally scoped objects, though there is always the possibility of a session sneaking in there in the future (perhaps for paging functionality in LDAP deployments)<br>
<div><div><br>
<br>
<br>
<br>
<br>
----- Original Message -----<br>
From: "Stef Telford" <<a href="mailto:stelford@internap.com" target="_blank">stelford@internap.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
Sent: Wednesday, August 1, 2012 1:19:48 PM<br>
Subject: [openstack-dev] [keystone] Accessing current Context from inside an Identity driver ?<br>
<br>
<br>
Hey Everyone,<br>
Recently, I have been digging in and around keystone, and there is a need for the current context to be made available to the identity driver rather than merely the manager. This is mostly so the identity driver can have the current roles for authee/user. I noticed in keystone/common/manager.py (where it ties everything together) that there is a note which says;<br>
<br>
<br>
<br>
def __getattr__(self, name):<br>
"""Forward calls to the underlying driver."""<br>
# NOTE(termie): context is the first argument, we're going to strip<br>
# that for now, in the future we'll probably do some<br>
# logging and whatnot in this class<br>
<br>
<br>
My question is, what's the "approved" solution to passing over the context ? I could always stuff the context into the **kw or append it to the args but, seems rather .. sub-optimal. Is there any design hints/tips ? I don't fancy maintaining a set of patches against the main branch jst for our codebase, and would rather do something to benefit everyone. I think this may come up again in the future ;)<br>
<br>
<br>
Regards<br>
S.<br>
</div></div>_______________________________________________<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>
<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>