On 8/14/07, Mark Ramm <[EMAIL PROTECTED]> wrote:
> I'm also hoping to recruit a few key people who care about this and
> have good ideas to work on it with us.
I'm quite keen to work on this.
> First, I think Identity has a good syntax for checking authorization,
> and if we can keep that syntax but have a more plugable backend we'll
> be in really good shape.
I'm not sure the primarily-decorator syntax for Identity really fits
in with the Pylons way of doing things. Or, at the very least, a way
to do things without using the decorator syntax would be very useful.
In one project (which doesn't use the object dispatcher), I had to
resort to:
def _f(_a, _b):
pass
identity.require(self.permission_requires)(_f)(None, None)
I didn't want to copy the exact code in identity.require, since then
I'd have to update it if it changes.
> Second, Authentication and Authorization should probably be split out
> into separate packages. To that end, I think we really need a robust
> authorization system implemented in WSGI middleware, that is usabel by
> TG, Pylons, raw WSGI apps, and anybody else who wants it. At the
> moment it looks like AuthKit seems to be the best candidate to become
> that, but it needs a bit of continuing love to make it into all it
> could be.
Just to make sure I understand how things fit together, AuthKit
currently does both Authorization and Authentication.
Authentication comes in two related parts - there's an authentication
middleware that catches authorization failures and turns those into
attempts to log in, and there are a number of authentication "plugins"
that can log users on based on different mechanisms.
Authorization comes in two related parts too - there's the
authorization middleware, decorators, and functions (much like
identity.require and SecureObject and so forth) that then use
permission objects (much like conditions in identity).
> Beyond that, I think the identity API is good (well, I'm not sure
> about the visit tracking stuff, but the rest of it for sure!). And
> it would be great to have a separate project be started to give that
> some love and make it work great for both TG and Pylons users.
> TurboPeakSecurity is another option, that we can consider, but I don't
> want to make it the default in tg2 just yet.
It should be easy to have the additional *args and **kwargs from the
controller's action to be passed through to the Identity Conditions,
which should then make using TurboPeakSecurity or something similar
via Identity easy enough.
One challenge here is that Pylons passes through values identified in
the path with routes to the action as keyword arguments, and
TurboGears passes values from the path components as positional
arguments and GET/POST parameters as keyword arguments.
I suspect that it might be easier to reimplement the authorization
part of the Identity API using the Authkit authorization
functions/permissions - since they already know about WSGI.
That also solves the whole *args and **kwargs problem I mentioned
two-to-three paragraphs back - we could just use the WSGI routing args
and params data. Although touching wsgi.input is probably not
something we want to do for posts? Will TG2's keyword argument
provider to actions already have read wsgi.input? Will Pylons have?
Neil
--
Neil Blakey-Milner
http://nxsy.org/
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
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?hl=en
-~----------~----~----~----~------~----~------~--~---
