[Zope-dev] RE: objectIds accessiblilty & and a proposal

[Toby Dickenson]

> -----Original Message-----
> From: Dieter Maurer [mailto:dieter@handshake.de]

> Toby Dickenson writes:
>  > > ... protocol specific access rights ...
>  > Please No.
>  > 
>  > Zope security is complex enough without having to worry about
>  > different security settings depending on how a method is accessed.
>  > (And we should have a lower tolerance for complexity when 
> it applies
>  > to security)
>  > 
>  > If a user has permission to access a method then he should 
> be able to
>  > access it any way (xmlrpc, ZPublisher, DTML, PythonMethods)
> I agree with you mostly.
> 
>    But it might be a significant difference, whether
>    you access via HTTP or HTTPS or even a protocol that
>    provides trusted authentication.

As a matter of principal, authentication issues do not belong in the
permissions machinery, but rather in the User machinery. As a matter of
practicality, changing the user machinery is also the smallest change that
achieves what you want.

What if it was possible to specify per-user the level of security required
(Basic is ok for some users, another needs https, etc). You could do this
today with a custom user folder, but it might make sense to add it to the
standard one.

Your very-private-method could then be protected by a permission that is
only given to users who are configured to require https.

This obviously works for normal users, but it applies to anonymous users
too....


The word 'zen' hasnt been used on the list for a while, so ill drop it in
here.... Zope has a standard "Anonymous" user who represents users who do
not authenticate. This user has no management interface, and he has a fixed
set of roles - this makes him very limited. However, you *dont* *need* *to*
*use* *it*. Create your own substitute as a new user (I like to call him
"Anon") in the root folder with a blank password.

This is useful if you create a product with a feature that you want to make
available anonymously today, but may want to authenticate in the future. You
could tweak the permissions mapping so that the appropriate permissions are
given to the "Anonymous" role, however that leads to alot of re-tweaking
when you make the change. A better solution is to create a new role, and
grant that role to "Anon". This step (granting special roles to the
anonymous user) is the thing you cant do with the regular anonymous user.

I hope this helps,