[Zope] ZClass security : a solution
Bowyer, Alex
BowyerA@logica.com
Thu, 30 Nov 2000 09:16:31 +1100
Seb, you were right, I was referring to ZClass security, which is very
poorly documented. And no you're not being intellectually lazy, that
sentence does make no sense!!!!
I have kind of got a working solution now, so I will share it for anyone
interested:
To recap, the scenario is a news page with a DTML method for viewing which
is accessible by all but also DTML methods for editing the content, which
are only to be available to users holding a certain role, which I happen to
have called UAAdmin (if you're wondering what UA is, it's the name of the
newsletter "Update Australia"). Each instance of the class is a separate
news page.
What I did is this, it's a bit of a messy solution but it works for me:
1) Create a role at the root level of Zope called UAAdmin (I keep all roles
at this level for simplicity).
2) At the level which instances of the news page class are to be created, go
to the Security tab and assign permissions to the UAAdmin role. If possible
include at least one permission which is not held by any other roles or
users at this level (other than the Manager of course). In my case "Manage
properties" could only be done by UAAdmin or Manager roles. This could be
anything, even something you don't use such as perhaps "Add ZGadfly Database
Connection" (ZODBC is much better!).
3) Within your ZClass class definition, for each DTML method you want to
assign security to:
a) Go to the 'Define Permissions' tab
b) Go to the dropdown next to 'View' and change "View" to "Manage
properties" (or whatever permission was unique to the role you want to give
access to). For methods that should have anonymous access, leave it as
"View"
You will find that this will have the desired effect of limiting access to
those pages/methods only.
Essentially what we are doing is saying "If you want to View this object,
you have to have the Manage Properties permission"
There are probably better ways, but if it ain't broke don't fix it.
I don't understand why you have to choose a permission for each permission
(which is a very confusing concept). It would be much better if you could
choose a role to say e.g. "If you want to View this object, you have to have
the UAAdmin Role"
Apparently there's something called ZPermissions where you can create your
own, so I could create a permission "Manage News Pages" and then say "If you
want to View this object, you have to have the Manage News Pages permission"
but I never worked this out fully.
If anyone has any suggestions for improvement, by all means put me straight,
but this worked for me.
Thanks
Alex
==================================
Alex Bowyer
IT Contractor, Logica Australasia
Tel : +61 2 9202 8130
Fax : +61 2 9922 7466
E-mail : bowyera@logica.com
WWW : http://www.logica.com.au/
==================================
> -----Original Message-----
> From: seb bacon [mailto:seb@jamkit.com]
> Sent: Thursday, November 30, 2000 12:53 AM
> To: Dieter Maurer
> Cc: Bowyer, Alex; 'zope@zope.org'
> Subject: Re: [Zope] security
>
>
> * Dieter Maurer <dieter@handshake.de> [001128 00:12]:
> > Bowyer, Alex writes:
> > > Can some one explain how the Define Permissions screen
> works. I really don't
> > > understand the concept behind it, what does it mean for
> a permission setting
> > > to own a permission?
> > >
> > > All I need to do is to make certain ZClass methods have
> a certain level of
> > > security and the other methods of the class have no security.
>
> > It is quite good explain in the upcoming Zope book.
>
> In fact, I think Alex was referring to ZClass security, which isn't
> covered in the book, and is something I've never go to the
> bottom of either.
> on the 'define permissions' tab, it says:
>
> The table below has two columns. The first column lists the
> permissions for this object. The second column specifies the
> permissions that should have this permission in this product
> or ZClass.
>
> I'm probably being intellectually lazy or something, but that doesn't
> make any sense to me at all.
>
> seb.
>