<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 08/02/2012 10:52 AM, Stef Telford wrote:
<blockquote
cite="mid:CAGP-STM53W9CXWJEMJVdrdMxE5kBCSWDK6LDydM_9C8cefvyXA@mail.gmail.com"
type="cite">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>
</blockquote>
<br>
What is it with you guys calling me names? I never was, nor ever
will be, one of the cool kids!<br>
<br>
Heh.<br>
<br>
DI can be abused, and most of the implementations I've seen have
been horrific, especially in Java. With Python, we can have a much
lighter touch, and keep things Pythonic. I'm working on a clear
example that I will post shortly.<br>
<br>
<br>
The identity driver gets called from the routes established at the
WSGI level, including what information to pass to the function.
Probably the easiest place to see things is in <br>
<br>
keystone/service.py: the class AdminRouter(wsgi.ComposingRouter):
registers the routes in its constructor:<br>
<br>
mapper.connect('/tokens',<br>
controller=auth_controller,<br>
action='authenticate',<br>
conditions=dict(method=['POST']))<br>
<br>
so this is going to find a variable named auth_controller and call
the authenticate method on it, passing in a dictionary. This
resolves to the TokenController (in the same file) and the
authenticate method, at around line 263. context is the first
parameter there.<br>
<br>
Many of the routes you would be interested in are defined in the
AdminRouter inside keysteon/identity/core.py and have the context
parameter in the first position.<br>
<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAGP-STM53W9CXWJEMJVdrdMxE5kBCSWDK6LDydM_9C8cefvyXA@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:stelford@internap.com" target="_blank">stelford@internap.com</a>><br>
To: <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>