[Grok-dev] post 1.0 Grok development wishlist
sylvain at infrae.com
Mon Oct 26 04:59:59 EDT 2009
On Tue, 06 Oct 2009 19:25:30 +0200
Martijn Faassen <faassen at startifact.com> wrote:
> Hi there,
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
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
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:
def doMe(self, bla, blabla):
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.
lastDone = interface.Attribute()
def doMe(bla, blabla):
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
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
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
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
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
If anyone have comments, I would love to have them. Maybe someone
have a better way/idea to define security.
Sylvain Viollon -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands
More information about the Grok-dev