[Grok-dev] post 1.0 Grok development wishlist

[Sylvain Viollon]

On Mon, 26 Oct 2009 09:59:59 +0100
Sylvain Viollon <sylvain at infrae.com> wrote:

Hello,

   Anybody have any idea about I proposed here ?

   Anybody is interested about the topic ?

   Best regards,

   Sylvain,

> 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