I'm writing my first Zope product. It's a folder-like object. I'm implementing before_publish_traverse() so that I can do authentication (but not using Zope's security model). Authentication logic is different depending on whether or not the managment view of the resource is being sought. Does anyone know if there is a way to tell programmatically whether the management view of a resource is being requested, other than looking for 'manage_workspace' as the last element in the path?
Edward Hartfield wrote:
I'm writing my first Zope product. It's a folder-like object. I'm implementing before_publish_traverse() so that I can do authentication (but not using Zope's security model). Authentication logic is different depending on whether or not the managment view of the resource is being sought.
Does anyone know if there is a way to tell programmatically whether the management view of a resource is being requested, other than looking for 'manage_workspace' as the last element in the path?
No. Management views are only published methods just as anything else. Most of them start with 'manage' but you can't count on all to do that. I've use the View permission to indicate that something isn't a management view. Why do you need different authentication logic? -- Johan Carlsson Tel: + 46 8 31 24 94 Colliberty Mob: + 46 70 558 25 24 Torsgatan 72 Email: johanc@easypublisher.com SE-113 37 STOCKHOLM
Johan Carlsson wrote: Why do you need different authentication logic? My client wants to do form-based authentication and have user data stored in a database so they can manage users without having to know anything about Zope. My idea is to create a folder object that can be given a method (AuthenticateMethod) to call when someone tries to traverse the folder's contents. AuthenticateMethod returns true or false. The folder itself knows nothing of the authentication scheme. That's AuthenticateMethod's concern. My partner and I agree that it doesn't make sense to throw away Zope's built-in security. But we don't like the hack required to logout a user with basic authentication. Also, we need to implement a record-level authorization scheme. The easiest, most cost-effective way to do this seems to be using a database to define user permissions just the way we want. I'd welcome any thoughts you or anyone else might have.
On Thu, Sep 09, 2004 at 09:30:51AM -0500, Edward Hartfield wrote:
Johan Carlsson wrote: Why do you need different authentication logic?
My client wants to do form-based authentication and have user data stored in a database so they can manage users without having to know anything about Zope.
Lots of people do this. The usual way is to use a UserFolder that interacts with your data source. If you want to do something custom, SimpleUserFolder is a nice place to start, it provides examples of getting users from SQL.
My idea is to create a folder object that can be given a method (AuthenticateMethod) to call when someone tries to traverse the folder's contents. AuthenticateMethod returns true or false. The folder itself knows nothing of the authentication scheme. That's AuthenticateMethod's concern.
And this method would presumably make requests to your database? Hmm. Here's an alternative that was suggested to me when I had some similar requirements, and worked out pretty well: let the User object do it instead, by supplementing its local roles. First, decide what role you will use for protecting your Zope data. You only need one role. Let's call it 'myrole'. Give that role "View" (or whatever) permissions on the data you're restricting. Don't grant the role to any users - your User object will be dynamically granting itself this role depending on the context object and your own authorization rules. Here's a way to do that: Subclass a UserFolder implementation (such as SimpleUserFolder) and have its getUser() method return a custom User class. Define a method of this user class named something like _getExtraRolesInContext(self, object), which, given a context object, does your database lookups or whatever, and returns either ['myrole'] if you want to authorize or [] if you don't. Next, write a trivial getRolesInContext() method that adds the output of the parent class' getRolesInContext() to _getExtraRolesInContext(). Finally, wrap the base class' allowed() method, something like: def allowed(self, object, object_roles=None): """Return true if the user has one of the given roles in the context of object. sadly, getRolesInContext is not called by this in the base class, or we wouldn't have to define this method. """ if object_roles is None: return 0 extra_roles = self._getExtraRolesInContext(object) for role in object_roles: if role in extra_roles: if self._check_context(object): return 1 # fall back to the old behavior return TheBaseClass.allowed(self, object, object_roles)
My partner and I agree that it doesn't make sense to throw away Zope's built-in security.
Good :-) I don't even know how you could possibly do so.
But we don't like the hack required to logout a user with basic authentication.
Have you tried CookieCrumbler?
Also, we need to implement a record-level authorization scheme.
I assume by "record" you mean an individual persistent object in Zope?
The easiest, most cost-effective way to do this seems to be using a database to define user permissions just the way we want.
You can do this in the scenario I described above. It's really not much work, and it allows you to keep data in any Folder-like containers you wish. The authentication/ authorization magic is entirely encapsulated by the UserFolder and User. For one thing this just feels cleaner to me; for another thing, you won't have people wondering why security is broken because they accidentally added a vanilla Folder or Plone Folder or whatever. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
On Thu, Sep 09, 2004 at 09:30:51AM -0500, Edward Hartfield wrote:
Johan Carlsson wrote: Why do you need different authentication logic?
My client wants to do form-based authentication and have user data stored in a database so they can manage users without having to know anything about Zope.
Lots of people do this. The usual way is to use a UserFolder that interacts with your data source. If you want to do something custom, SimpleUserFolder is a nice place to start, it provides examples of getting users from SQL.
My idea is to create a folder object that can be given a method (AuthenticateMethod) to call when someone tries to traverse the folder's contents. AuthenticateMethod returns true or false. The folder itself knows nothing of the authentication scheme. That's AuthenticateMethod's concern.
And this method would presumably make requests to your database?
Hmm. Here's an alternative that was suggested to me when I had some similar requirements, and worked out pretty well: let the User object do it instead, by supplementing its local roles.
First, decide what role you will use for protecting your Zope data. You only need one role. Let's call it 'myrole'. Give that role "View" (or whatever) permissions on the data you're restricting. Don't grant the role to any users - your User object will be dynamically granting itself this role depending on the context object and your own authorization rules. Here's a way to do that:
Subclass a UserFolder implementation (such as SimpleUserFolder) and have its getUser() method return a custom User class. Define a method of this user class named something like _getExtraRolesInContext(self, object), which, given a context object, does your database lookups or whatever, and returns either ['myrole'] if you want to authorize or [] if you don't.
Next, write a trivial getRolesInContext() method that adds the output of the parent class' getRolesInContext() to _getExtraRolesInContext().
Finally, wrap the base class' allowed() method, something like:
def allowed(self, object, object_roles=None): """Return true if the user has one of the given roles in the context of object. sadly, getRolesInContext is not called by this in the base class, or we wouldn't have to define this method. """
if object_roles is None: return 0 extra_roles = self._getExtraRolesInContext(object) for role in object_roles: if role in extra_roles: if self._check_context(object): return 1 # fall back to the old behavior return TheBaseClass.allowed(self, object, object_roles)
My partner and I agree that it doesn't make sense to throw away Zope's built-in security.
Good :-) I don't even know how you could possibly do so.
But we don't like the hack required to logout a user with basic authentication.
Have you tried CookieCrumbler?
Also, we need to implement a record-level authorization scheme.
I assume by "record" you mean an individual persistent object in Zope?
The easiest, most cost-effective way to do this seems to be using a database to define user permissions just the way we want.
You can do this in the scenario I described above. It's really not much work, and it allows you to keep data in any Folder-like containers you wish. The authentication/ authorization magic is entirely encapsulated by the UserFolder and User. For one thing this just feels cleaner to me; for another thing, you won't have people wondering why security is broken because they accidentally added a vanilla Folder or Plone Folder or whatever.
Thanks. I intend to try this.
Edward Hartfield wrote:
Johan Carlsson wrote: Why do you need different authentication logic?
My client wants to do form-based authentication and have user data stored in a database so they can manage users without having to know anything about Zope. My idea is to create a folder object that can be given a method (AuthenticateMethod) to call when someone tries to traverse the folder's contents. AuthenticateMethod returns true or false. The folder itself knows nothing of the authentication scheme. That's AuthenticateMethod's concern.
My partner and I agree that it doesn't make sense to throw away Zope's built-in security. But we don't like the hack required to logout a user with basic authentication. Also, we need to implement a record-level authorization scheme. The easiest, most cost-effective way to do this seems to be using a database to define user permissions just the way we want.
I'd welcome any thoughts you or anyone else might have.
It sounds like Paul gave you a set of good advice. My initial feeling was that you were trying to solve a problem that is already solve in Zope. You can accutally to pretty much you can do with Zope's security system, specially the local_roles support, if you take a deeper look. It will save you hours of work in the long run. As we say: "Use the source Luke". Zope source is easy too read and worth the while. (IMHO it much better that the Zope Book ;-) -- Johan Carlsson Tel: + 46 8 31 24 94 Colliberty Mob: + 46 70 558 25 24 Torsgatan 72 Email: johanc@easypublisher.com SE-113 37 STOCKHOLM
Edward Hartfield wrote at 2004-9-9 09:30 -0500:
Johan Carlsson wrote: Why do you need different authentication logic?
My client wants to do form-based authentication and have user data stored in a database so they can manage users without having to know anything about Zope.
Look for SimpleUserFolder or ExUserFolder, maybe together with CookieCrumbler. -- Dieter
participants (4)
-
Dieter Maurer -
Edward Hartfield -
Johan Carlsson -
Paul Winkler