[Grok-dev] grok and complicated permissions
Brandon Craig Rhodes
brandon at rhodesmill.org
Wed Sep 26 12:53:40 EDT 2007
I have read PvW's book and also example Grok code, and am not finding
a complicated enough security scheme for my needs. It looks like the
default scheme (which is similar to the one used in Plone 2) involves
giving actors permissions expressed as strings ('Create mammoth') and
then saying that certain grok.Views (or, in pure Zope 3, that certain
object attribute accesses) require that permission.
1) I need more interesting rules. For example, if "Change password"
is a permission required to use my "ChangePasswordView", then in
my case it will depend on the combination of who is attempting the
change and whose account they are acting on. The rule will be
something like: "If you are a campus-wide admin, you can change
the password of any account; but if you are department-hired
admin, then you can only change the passwords of users who work
for your department."
If I were to attempt this with the default permissions scheme, I
would have to create tens of thousands of permissions - one for
every account ("Change password of br32", "Change password of
ms94", and so forth) and then constantly grant and revoke them as
admins moved between departments.
It feels like I ought to be able to register a multi-adapter that
adapts the agent, the object, and the attribute being accessed,
and that returns a decision-maker that can compute whether the
access should be allowed. But I'm reading through zope.security
and have not yet found something like that, so I thought I'd stop
and ask for advice. :-)
2) Part of what attracted me to Zope 3, as I read PvW's book, was
that objects can be protected rather than views. I like the idea
of saying what can and can't be done to objects themselves.
If I have to protect an account from having its password changed,
for example, I can restrict access to its "change_pw()" method and
know that no present or future View will accidentally get coded in
such a way as to let an agent run the method.
Do we have a story yet for how Grok security, which from what I
can tell is built around Views, can be pushed back down on to
objects and their attributes? One of the things that I have,
actually, enjoyed about Plone is that if you protect a piece of
content, then it magically disappears from both its own views and
all views of its container (of which there are sometimes two or
three that might list or let you rename the object!) for not
authorized users, but everything else on each page continues to be
displayed for them. It's neat to be able to create complex views
that show a dozen things, and know that one of the dozen will be
missing but leave the page functioning if a security setting turns
off access to it.
Brandon Craig Rhodes brandon at rhodesmill.org http://rhodesmill.org/brandon
More information about the Grok-dev