[Grok-dev] grok and complicated permissions

[Brandon Craig Rhodes]

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