[Grok-dev] post 1.0 Grok development wishlist

[Sylvain Viollon]

On Tue, 06 Oct 2009 19:25:30 +0200
Martijn Faassen <faassen at startifact.com> wrote:

> Hi there,
> 

   Good morning,

   I have been busy, and thinking.

> In the hope of prompting some discussions and development activity,
> here is a list of post 1.0 Grok wishlist items I have or know about:
> 
> [...]
> 
> 
> * megrok.layout integration. Look into integrating megrok.layout 
> functionality into the Grok core. This would require some discussion
> on megrok.layout to see what shape this integration could best be
> like.
> 

  As I use heavily that package in Silva (since I somehow made it in
  Silva), I would like to work on that as well, as it's a feature I
  already use.

  So if there is people interested to brainstorm, I am all open.

  If JW and Jan Jaap are interested maybe we can setup some kind of
  local sprint a Friday afternoon at Infrae to talk about it (since we
  are in the same city).

> * z3c.hashedresource and hurry.resource integration. Some work was
> done at the sprint to explore this.
> 

  I use my own cooked things for resources now, based in
  z3c.resourceinclude, but I am not 200% satisfied, I am interested
  to see how things are going here as well. 

> * declarative model-level security decorators/directives, for the
> case where Grok's "view-only" security system isn't enough and
> security proxies are desired.
> 

  That last point is the one which interest me the most. There two
  things I can think of:

  - a decorator, which takes a permission and protect that method with
    the given permission. As soon as you specify one decorator in your
    class, all non-specified authorized access are forbidden, i.e. you
    need to declare each method you want to access using a decorator:

    class MyContent(grok.Model):

       @grok.require('my.permission')
       def doMe(self, bla, blabla):
           pass


    The decorator could take an instance of grok.Permission as well.

    It sounds like in Zope2 with security.declarePrivate calls.

    It sounds easy as well, to understand, and write.

    But it doesn't sounds complete: I want to be able to protect
    attributes as well, with one permission for view, and one for set.

  - so we could create two directives, one for view, one for set (so
    it cover the property usecase). They takes an interface, and a
    permission, and do their jobs. If you don't set a view directive
    but a set, the view fallback to the same permission than the view.


    class IMyContent(grok.IContext):

        lastDone = interface.Attribute()

        def doMe(bla, blabla):
            pass


    class MyContent(grok.Model):

        grok.restrict(IMyContent, 'my.changepermission')
        grok.restrictAccess(IMyContent, 'my.viewpermission')

        ...
    

    It's nice because this does everything I want of (in fact it's just
    a translation of the ZCML configuration in grok directives, it's
    not that original).

    But you need to write interfaces to declare your security.
    Interface are always a good thing anyway, but it sound complicated
    for Grok newbies, whenever the first solution sounds more easy to
    understand.

    It might be shorter for complex declaration: you don't have to
    repeat 20 times the grok.require with the same permission for a
    class with 20 methods.

  I think the best will still be only to implement the second 'idea' as
  if you need to setup content-level security, that means your
  application is complex, and so you are not a newbie anymore, so you
  can understand and write interfaces. But if someone want the first
  one anyway, I think it's doable in a megrok.something extension to
  have it.

  In both case, I propose the default security should be 'open' for a
  class. If you specify a security definition on a class, all
  non-declared attributes should be forbidden of access (let say
  'closed').

  For people who want to enforce security everywhere, I think that
  megrok.strictrequire could check that.

  Anyway I think everybody will agree that, that code should end up in
  grokcore.security.

  Note: all the directives name I propose are just the one who popup in
  my mind when writing that mail. I am sure we can think of something
  better.

  If anyone have comments, I would love to have them. Maybe someone
  have a better way/idea to define security.

  Best regards,

  Sylvain,

-- 
Sylvain Viollon -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands