I'm getting a little confused with the Slides user management too ;) I use JDBC-Realm and I've successfully implemented PHP-methods for managing Slide's users and permissions with WebDAV protocol. It works in a following way:

When I want to add an user I'll just do a MKCOL username to /users -collection. Removing is done by deleting the folder. When I want to create a group I'll do the MKCOL in the /roles -collection. To add/remove users to a group I modify the group-member-set of the /roles/groupname - collection.

Everything seems to work fine, except I can't remove an existing goup (role?) collection from the /roles -collection (I get the HTTP-500 error).

Mikko Hämäläinen

From: Michael Smith <[EMAIL PROTECTED]>
Reply-To: "Slide Users Mailing List" <[EMAIL PROTECTED]>
To: Slide Users Mailing List <[EMAIL PROTECTED]>
Subject: Re: Slide realm and permissions
Date: Thu, 29 Apr 2004 11:00:11 +1000

Ollie wrote:

Thanks that is as I expected. We want to run other applications on
> the same Tomcat using a different Realm. It seems to me that the Slide
> Webapp should be able to use a role setup in the Tomcat realm as
> other webapps seem to be able to do.

You can definately do this - if by "use a role" you mean "allow or disallow access according to container-managed-security". If you want to do anything more detailed within slide, your options are much more limited.

This is mostly because there's a real mismatch between the servlet spec (which uses roles) and the webdav (ACL) spec, which uses groups. The two are fundamentally different (in ways which aren't obvious to everyone, but basically: a group can have its children enumerated, a role cannot).

My last attempt to tackle this problem (and things may have changed since, I'm intending to look at the details of this problem again very soon) led me to decide that there was no way to manipulate ACLs involving roles (which the slide core supports) via the webdav ACL protocol.

Reformulating the problem so that you can tackle it using groups is, in my opinion, a better solution. Roles are a nice abstraction for thinking about high-level authorisation problems, but groups provide a mechanism that works better in practice for large-scale deployments where you have to interoperate with other systems.

We are looking at a patch that will update the member list of a role
> metadata when a child collection is added or removed from that role
> collection object similar to the method for user collection objects
> added as child collection to the /users/ collection adds a user.

I'm not sure what you mean here? A role has no member list.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Nopea ja hauska tapa lähettää viestejä reaaliaikaisesti - MSN Messenger. http://messenger.msn.fi Lataa nyt käyttöösi ilmaiseksi.

--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to