Ben Bangert wrote:
> Pretty easy really. When the ID is called, it initializes the
> thread-local. That way when you do import Identity from TG Blog, it
> looks at the thread-local, which was setup by ID. When you setup each
> ID, you of course tell it how its going to do the lookup, which it
> saves. Then when its called, it looks at how it was initialized, loads
> it up, sets the thread-local, and proceeds.
>
Sorry - I should have included the Authorization part of the diagram
(was assuming it was there). Remember this (slight change)?
def __call__(self, environ, start_response):
tgEnviron(environ) # Make sure environment has things in place
if not environ['path_info'][0] in ['Login','Logout']:
environ['authorization'].check(role='Admin')
return self.defaultCall(environ, start_response)
It needs to be able to call the *right* version from deep inside the
code. You're right: wrapping is easy for the ID part. I'm making a
distinction between getting the user ID (Identity) and checking the
permissions (Authorization). Authorization can be done deep down in
the code and may require a direct call to the particular Identity
middleware. I guess I see it this way:
Environ verison:
ID: set environ['authorization'] to ID local class (self most
likely).
Auth: call environ['authorization'].method to check.
Library version:
Make sure identity.py is installed by any ID conforming modules.
ID: allocate new thread-safe location and put self there.
Auth: Call identity.py function which will (Given current thread
ID), lookup ID object and return with it. Call the auth method.
Somehow, you're implying that there's an "identity.py" installed in
site-packages that these two different ID packages are sharing (it
could be that LDAP ID and MySQL ID are part of completely different
packages). Who installs it? Do both of them have a "identity.py" in
their install packages? I'm just saying that it's easier to share a
namespace (politically) than it is to share code.
The libarary version just seems to add a whole lot of complexity. It
adds the requirement that there's a common module that is shared among
all ID providers (basically you're using the library namespace rather
than the environ namespace), it forces creation of yet another
thread-safe region (which I think does a lock under the covers), and it
just slows things down. And I'm not sure what it buys you. Either
method can be used stacked or unstacked.
> Oh, its not just a thread-safe module global.... :) Keep in mind that
> your app might call a differently configured version of the same app
> farther down the chain. That app would then blast away your thread-safe
> module global, and when its done, the app farther in the chain would be
> left using data that wasn't its own.
You're right that it could be that a lower-level Identity module may
blow away what was above, but that's what you'd want, right? Whoever
is last on the stack has control.
> [ neat GlobalRegistry stuff deleted]
I like the GlobalRegistry idea - I just don't think you can get all the
Frameworks to agree on it. I'm mostly thinking small and subversive,
here :-). BTW, to implement the globalregistry, I'd just use
environ['globalregistry'].
> I should also mention that putting things in environ doesn't solve this
> problem. Just imagine the same scenario, only you're storing your ID
> object in environ. If one of your apps down the chain uses ID as well,
> it will blow the prior ID object in environ away....
The question is: what's wrong with this? That's the behaviour that
you'd expect; the only time you'd want to go back up is with an
exception, and the local variables will be fine to store the ID state
for a redirect. But I can see cases where you'd want a stack. But
that's tangental to the environ/library thing.
> so regardless of
> if its a thread-local or in environ, it needs to be a stacked style
> object.
Just curious, though: when do you ever pop?
Cheers,
Gary
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
