Hello, Christoph.
I think we need a new thread already to discuss this. I'm sure many people
already stop reading this thread and are not aware of this new topic, and thus
they don't participate. :-/
On Wednesday February 4, 2009 03:07:10 Christoph Zwerschke wrote:
> Gustavo Narea schrieb:
> > On Tuesday February 3, 2009 17:03:55 Christoph Zwerschke wrote:
> >> Using repoze.what.credentials instead of repoze.who.identity sounds
> >> like a good idea to me, and I will use it in the future. This was
> >> however not mentioned in the TG 2 docs either (don't expect
> >> newbies to read the last passage of the last page "inner workings"
> >> of the external docs ;-)
> >
> > Developers shouldn't deal with the repoze.what credentials dict, it's
> > not part of the repoze.what API, unlike the repoze.who identity dict
> > -- that's what predicate checkers are for.
>
> Ok, though I don't fully understand why you handle it differently than
> repoze.who and don't simply make the credentials app part of the API (at
> least the "groups" and "permissions" entries).
Simple: repoze.who handles authentication and identification, and
identification data must be at hand. Authentication and authorization data
don't have to.
> Yes, there are predicates, but I see predicates as an additional tool
> to restrict access by checking authorization (but may be used also to
> check authentication, e.g. the "is_user" predicate), i.e. something
> based on top of both repoze.who.identity and repoze.what.credentials,
> but not as a replacement for repoze.what.credentials.
They are neither replacement nor alternative to repoze.what credentials. They
just happen to use the credentials internally; the credentials are not even
part of the API.
> Even when
> predicates are now improved so that has_permission can be evaluated as
> boolean, you still have no standard way of getting all permissions or
> groups of a user (sometimes I needed the latter).
With systems like Catwalk in mind, which may provide information about how the
auth system is working, I've created a couple of functions which return the
current groups and permissions, respectively, in repoze.what v2 (but it's one
of the things I'll backport to v1).
Groups and permission are going to evolve. They won't be as simple as "zero or
more users belong to a group" and "zero or more groups are granted a
permission" forever. Among other things, they'll become hierarchized (e.g.,
"group A is the parent of group B, so anyone who belongs to B also belongs to
A"). So, those tuple of strings at credentials['groups'] and
credentials['permissions'] will disappear as things turn more complex
internally -- that is why the credentials dictionary won't be part of the API.
> > Although it's worth noting that predicates in repoze.what-1.0.4 (not
> > yet released; current trunk) already support the following:
> > >>> from repoze.what.predicates import has_permission
> > >>> p = has_permission('edit-posts')
> > >>> p.is_met(environ)
> > True
>
> That's good, but it still is not as simple as "'edit_posts' in
> tg.credentials". And if you want to use it in a template, you need to
> import or pass has_permission, plus feed the environ, or your proposed
> "evaluate" function.
>
> Sorry to be such a pain in your neck, but I really think checking
> permissions in a template should be as simple as
>
> 'edit' in tg.credentials or tg.acess.has_permission('edit')
>
> Here is a possible implementation of the latter (this is like what I
> suggested in an earlier post):
>
> ----------------------
>
> from tg import request
> from repoze.what import predicates
>
> class Access(object):
> """Environ-aware predicates which check immediately."""
>
> def __getattr__(self, name):
> predicate = getattr(predicates, name)
> if callable(predicate):
> def predicate_is_met(*args, **kwargs):
> return predicate(*args, *kwargs).is_met(
> request.environ)
> return predicate_is_met
> else:
> return predicate
>
> access = Access() # make this a standard tg template variable
>
> ----------------------
>
> tg.acess takes any of the standard predicates as attribute and evaluates
> that predicate immediately. We could also provide a mechanism to include
> custom predicates in tg.access. This is of course a hack for TurboGears
> only, I don't say it should be somehow included in repoze.what.
> Something like that would just help to keep simple things simple in TG.
I'm +0.5 on that, and I wouldn't mind implementing it if we raise this on a
new thread and people agree. ;-)
Cheers!
--
Gustavo Narea <http://gustavonarea.net/>.
Get rid of unethical constraints! Get freedomware:
http://www.getgnulinux.org/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" 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-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
