RE: patch for auto-create-users
Attached is a patch for auto-create-users against version 2.0 of slide. I've added the following methods to the Macro interfasce: /** * Adds a user. * * @param root The token to use to create the user. * @param user The name of the user to create. * @throws MacroException If an exception occurs. */ public void addUser(SlideToken root, String user) throws MacroException; /** * Adds a role. * * @param root The token to use to create the role. * @param role The name of the role to create. * @throws MacroException If an exception occurs. */ public void addRole(SlideToken root, String role) throws MacroException; /** * Add a user to a role. * * @param root The token to use to perform the operation. * @param user The name of the user to add to the role. * @param role The role to add the user to. * @throws MacroException If an exception occurs. */ public void addUserToRole(SlideToken root, String user, String role) throws MacroException; /** * Removes a user from a role. * * @param root The token to use to perform the operation. * @param user The name of the user to remove from the role. * @param role The role to remove the user from. * @throws MacroException If an exception occurs. */ public void removeUserFromRole(SlideToken root, String user, String role) throws MacroException; And corresponding implementations to the MacroImpl class. I haven't added methods to remove users and roles as this creates data integrity issues. The WebdavServlet has been modified to auto-create a user if configured to do so. The usage is as for the previous patch: It is configured with the following properties in Domain.xml: auto-create-users and auto-create-users-role These properties do not have the same definition as they did previously. auto-create-users specifies the user to use to create new users, so it must be a root user and auto-create-users-role specifies the role to add the new user to. If this property is not specified the user will not be added to any roles. A typical configuration would be: configuration ... auto-create-usersroot/auto-create-users auto-create-users-roleuser/auto-create-users-role ... /configuration The root user will be used to create new users. New users will be added to the user role. Let me know what you think. Jamie. -Original Message- From: Jamie Mortimore [mailto:[EMAIL PROTECTED] Sent: 26 April 2004 13:06 To: Slide Users Mailing List Subject: Re: patch for auto-create-users On Mon, 2004-04-26 at 10:52, Martin Holz wrote: I added a createUser method to the Content interface and implementation, ContentImpl. You may decide this is not the right place for a create user method if Content is only supposed to handle more low level operations. In which case the functionality could be moved to the only place createUser is called from - AbstractWebdavMethod.run. I have been thinking about MacroImpl as the right place or a new helper for higher level user management. Sounds good - I'll move the method(s) there. The createUser method takes 3 parameters: * root - The SlideToken to use to perform the necessary operations - this should have the credentials of a root user in order to perform the operations successfully. * userName - The name of the new user. * role - The role of the new user. Pass in null to create the user without any roles. Shouldn't this be a potentially empty list of roles? Potentially yes. I didn't add support for lists of roles as the previous version (if it had worked) didn't support it (not that that's a good reason not to add it). I was thinking about adding a set of methods along the lines of: addUser removeUser addRole removeRole addUserToRole removeUserFromRole I modelled the createUser method around what I could gather was being done in the XMLUnmarsheller during creation of users at startup. The createUser method is only called from one place - AbstractWebdavMethod.run. I am assuming this is an entry point for all wedav methods. The first thing this method now does is: The servlet would need it too, if it wants to create a directory listing for a GET on a collection. Are you saying there is a way webdav methods are called that do not go through AbstractWebdavMethod.run? Is there a more appropriate place to call the createUser method (eg at the start of WebdavServlet.service)? I'm going to be using slide on a project I'm working on at the moment and can devote some time to fixing any problems that would effect this project + any enhancements required. Would it be helpful if I provide a patch that includes the above against the latest cvs version of Slide? Obviously I don't want to spend time on another patch if someone else is already looking at integrating this functionality. Jamie
RE: patch for auto-create-users
When I first looked at slide I assumed it would use servlet container security (I wasn't familiar with the webdav spec). Clearly it can't use j2ee security and conform to the webdav spec. The ideal solution for me would be to have slide authenticate using LDAP and the servlet container use slide for authentication. I'm using Weblogic 8.1 and it is already configured to use LDAP for security so the route of least resistence to get authentication working is to automatically add users authenticated by the serlet container. Unfortunately - like Daniel says - this means the slide user database is out of sync with the LDAP database. To get the LDAP users and roles into slide wouldn't it be slightly more complicated than just writing a store for LDAP (even tough it sounds like this is pretty complicated). I would only want to use the LDAP store for the users and roles directories not the rest of the directories. I would have thought I would need a proxy store that would use the correct underlying store for different directories - LDAP for users and roles and JDBC for the rest, in my case. Another approach might be to import LDAP users and roles into slide and listen for updates on LDAP to keep the two in sync. Could you not make a store read-only by simply making sure no user had any write permissions? -Original Message- From: Martin Holz [mailto:[EMAIL PROTECTED] Sent: 26 April 2004 13:49 To: [EMAIL PROTECTED] Subject: Re: patch for auto-create-users Daniel Florey [EMAIL PROTECTED] writes: Hi, I'd propose to add the methods regarding the user/role stuff to the Security-Interface and the SecurityImpl-class. There already are some methods regarding user/role management (hasRole()...) This is not possible, since the methods need access to ContentImpl et. al. which are not available. Adding those helpers would create cyclic dependencies. In general I think it would be better to have only one place (e.g. LDAP) where users are managed and give slide the ability to access the LDAP-user/roles. This is definitely one way. It can be done right now, if you implement a LDAP store. However mapping LDAP groups to slide groups can be a real pain. As a side note slide has currently no concept of a read only store, which would be really useful here. What if you add a user and auto-create it in slide. After that you grant a permission to this user and delete the user lateron? The user will not be deleted in slide as no auto-delete can be done. So you have an inconsistent user database where some users in slide exist that don't exist in your primary user store anymore. Adding your propsed methods is a good thing anyway as many users might need some simple methods to create users and add roles at slide api level. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for auto-create-users
Mortimore, Jamie [IT] wrote: When I first looked at slide I assumed it would use servlet container security (I wasn't familiar with the webdav spec). Clearly it can't use j2ee security and conform to the webdav spec. The ideal solution for me would be to have slide authenticate using LDAP and the servlet container use slide for authentication. I'm using Weblogic 8.1 and it is already configured to use LDAP for security so the route of least resistence to get authentication working is to automatically add users authenticated by the serlet container. Unfortunately - like Daniel says - this means the slide user database is out of sync with the LDAP database. To get the LDAP users and roles into slide wouldn't it be slightly more complicated than just writing a store for LDAP (even tough it sounds like this is pretty complicated). I would only want to use the LDAP store for the users and roles directories not the rest of the directories. I would have thought I would need a proxy store that would use the correct underlying store for different directories - LDAP for users and roles and JDBC for the rest, in my case. It is possible to assign different stores to different scopes (like mount points), so you don't need the proxy thing. So the main task would be to write a LDAP-store. To have such a store would be really a great thing so that users and roles are stored only in one physical store. If LDAP provides some notification mechanism for informing slide about user/role updates additional user/role caching would be possible to achieve better performance. Regards, Daniel Another approach might be to import LDAP users and roles into slide and listen for updates on LDAP to keep the two in sync. Could you not make a store read-only by simply making sure no user had any write permissions? -Original Message- From: Martin Holz [mailto:[EMAIL PROTECTED] Sent: 26 April 2004 13:49 To: [EMAIL PROTECTED] Subject: Re: patch for auto-create-users Daniel Florey [EMAIL PROTECTED] writes: Hi, I'd propose to add the methods regarding the user/role stuff to the Security-Interface and the SecurityImpl-class. There already are some methods regarding user/role management (hasRole()...) This is not possible, since the methods need access to ContentImpl et. al. which are not available. Adding those helpers would create cyclic dependencies. In general I think it would be better to have only one place (e.g. LDAP) where users are managed and give slide the ability to access the LDAP-user/roles. This is definitely one way. It can be done right now, if you implement a LDAP store. However mapping LDAP groups to slide groups can be a real pain. As a side note slide has currently no concept of a read only store, which would be really useful here. What if you add a user and auto-create it in slide. After that you grant a permission to this user and delete the user lateron? The user will not be deleted in slide as no auto-delete can be done. So you have an inconsistent user database where some users in slide exist that don't exist in your primary user store anymore. Adding your propsed methods is a good thing anyway as many users might need some simple methods to create users and add roles at slide api level. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Controlling Slide cache, was Re: patch for auto-create-users
Hi, Daniel Florey wrote: If LDAP provides some notification mechanism for informing slide about user/role updates additional user/role caching would be possible to achieve better performance. I have a custom store that gets user/role info from an external source. I set it up in the Domain.xml and it's working but Slide caches the objects and do not go to my store to get updated info. I can also detect external updates, but how do I control the caching in Slide? I don't want to disable caching completely. Is there a way to invalidate a cache entry from within my store code? Thanks, Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Controlling Slide cache, was Re: patch for auto-create-users
ExtendedStore allows you to invalidate entries. Subclass it and add your code that talks to your client store to find out which entries to delete. Use something like getTxCache().remove(null, [key to be invalidated] on objectsCache, permissionsCache, etc. Oliver Carlos Villegas wrote: Hi, Daniel Florey wrote: If LDAP provides some notification mechanism for informing slide about user/role updates additional user/role caching would be possible to achieve better performance. I have a custom store that gets user/role info from an external source. I set it up in the Domain.xml and it's working but Slide caches the objects and do not go to my store to get updated info. I can also detect external updates, but how do I control the caching in Slide? I don't want to disable caching completely. Is there a way to invalidate a cache entry from within my store code? Thanks, Carlos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for auto-create-users
Daniel Florey wrote: It is possible to assign different stores to different scopes (like mount points), so you don't need the proxy thing. So the main task would be to write a LDAP-store. To have such a store would be really a great thing so that users and roles are stored only in one physical store. If LDAP provides some notification mechanism for informing slide about user/role updates additional user/role caching would be possible to achieve better performance. Regards, Daniel I went through the same progression as Jamie with auto-create-users. It would have been nice to have when I started, but it doesn't add anything now since I ultimately need the LDAP sync'd setup as well. Could you give an idea of just how much effort is involved in creating an LDAP store? I don't know if it makes it any easier, but I only need LDAP for usernames and passwords. I don't really even care if roles are stored in LDAP. Regards, Ryan Rhodes _ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.com/?pgmarket=en-uspage=hotmail/es2ST=1/go/onm00200362ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for auto-create-users
Ryan Rhodes [EMAIL PROTECTED] writes: I went through the same progression as Jamie with auto-create-users. It would have been nice to have when I started, but it doesn't add anything now since I ultimately need the LDAP sync'd setup as well. Could you give an idea of just how much effort is involved in creating an LDAP store? I don't know if it makes it any easier, but I only need LDAP for usernames and passwords. I don't really even care if roles are stored in LDAP. If you don't need groups, why do you need a sync with the LDAP-Server? This is a scenario where autocreate-users is really helpfull. Configure your servlet container to use LDAP authentication. If you delete a user, in LDAP the servlet container does not longer allow login (assuming the container does not cache to much). So nobody cares about a user node in slide which belongs to user which not longer exists in LDAP. Btw. deleting this user node might be problematic, if the user still owns files. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for auto-create-users
Well, I should restate that. I do need roles. I was actually hoping to use SlideRealm, because I want other parts of the webapp to use Slide roles for access control. The only reason I need LDAP is because usernames/passwords must all come from LDAP in the environments we are targeting. Once the user is created in Slide, I want SlideRealm to handle everything. The question is... how do you use an LDAP Realm for authentication, but a SlideRealm for authorization. I think I would need the SlideRealm to pull it's users from an LDAP store. Does any of this sound correct? --Ryan From: Martin Holz [EMAIL PROTECTED] Reply-To: Slide Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: patch for auto-create-users Date: 27 Apr 2004 17:32:51 +0200 Ryan Rhodes [EMAIL PROTECTED] writes: I went through the same progression as Jamie with auto-create-users. It would have been nice to have when I started, but it doesn't add anything now since I ultimately need the LDAP sync'd setup as well. Could you give an idea of just how much effort is involved in creating an LDAP store? I don't know if it makes it any easier, but I only need LDAP for usernames and passwords. I don't really even care if roles are stored in LDAP. If you don't need groups, why do you need a sync with the LDAP-Server? This is a scenario where autocreate-users is really helpfull. Configure your servlet container to use LDAP authentication. If you delete a user, in LDAP the servlet container does not longer allow login (assuming the container does not cache to much). So nobody cares about a user node in slide which belongs to user which not longer exists in LDAP. Btw. deleting this user node might be problematic, if the user still owns files. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get rid of annoying pop-up ads with the new MSN Toolbar FREE! http://toolbar.msn.com/go/onm00200414ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for auto-create-users
Ryan Rhodes [EMAIL PROTECTED] writes: Well, I should restate that. I do need roles. I was actually hoping to use SlideRealm, because I want other parts of the webapp to use Slide roles for access control. The only reason I need LDAP is because usernames/passwords must all come from LDAP in the environments we are targeting. Once the user is created in Slide, I want SlideRealm to handle everything. The question is... how do you use an LDAP Realm for authentication, but a SlideRealm for authorization. Don't use SlideRealm. The slide realm makes user/password combinations available to the servlet container. Any realm does not handle authorization. The servlet container does a coarse authorization based on the information in web.xml. If this authorization is successfull the implementation of org.apache.slide.Security will do a detailed authorization based on the information in the /users node. Slide ignores the results of javax.servlet.http.HttpRequest.isUserInRole(). Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for auto-create-users
Martin Holz wrote: Don't use SlideRealm. The slide realm makes user/password combinations available to the servlet container. I am not grasping this part. You mean that slide realm becomes the store for usernames/passwords that the servlet container authenticates against? Any realm does not handle authorization. The servlet container does a coarse authorization based on the information in web.xml. If this authorization is successfull the implementation of org.apache.slide.Security will do a detailed authorization based on the information in the /users node. Slide ignores the results of javax.servlet.http.HttpRequest.isUserInRole(). Martin I think we are in reverse here. I want to pull roles from Slide for other webapps. For instance, I might want to have a webapp with forums that are linked to slide groups, so that users of the webapp will browse the forums and only see the forums that are associated with the Slide Groups they belong to. I am thinking that the course authorization will be fine for apps that don't allow the users to directly manipulate the content tree. So... I want the webapps to use javax.servlet.http.HttpRequest.isUserInRole(), but I want the roles to come from Slide. Does this make sense? --Ryan _ MSN Toolbar provides one-click access to Hotmail from any Web page FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for auto-create-users
Hi Jamie!
Thanks for the patch :)
In order for me to evaluate could you please explain what you did in the
patch and why? What exactly was broken and what did you fix?
For future contributions could you please create the diffs using -u
instead of -c?
Thanks again,
Oliver
Jamie Mortimore wrote:
In version 2.0rc1 of slide the auto-create-users functionality is not
working.
The attached patch fixes the problem. With the new functionality enabled
users authenticated by the servlet container are added as users within
slide.
It is configured with the following properties in Domain.xml:
auto-create-users and
auto-create-users-role
These properties do not have the same definition as they did previously.
auto-create-users specifies the user to use to create new users, so it
must be a root user and auto-create-users-role specifies the role to add
the new user to. If this property is not specified the user will not be
added to any roles.
A typical configuration would be:
configuration
...
auto-create-usersroot/auto-create-users
auto-create-users-roleuser/auto-create-users-role
...
/configuration
The root user will be used to create new users. New users will be added
to the user role.
To apply the patch download the source for slide version 2.0rc1 and
extract it from the archive. Apply the patch from within the
jakarta-slide directory. On *n*x you would do something like:
$ tar -xzf jakarta-slide-server-2.0rc1-src.tar.gz
$ cd jakarta-slide
$ patch -p0 path-to-patch/jakarta-slide-server-2.0rc1-src.patch
You can now build the distribution following the normal instructions.
Jamie.
diff -rc ./src/share/org/apache/slide/common/NamespaceConfig.java ../../jakarta-slide/src/share/org/apache/slide/common/NamespaceConfig.java
*** ./src/share/org/apache/slide/common/NamespaceConfig.java 2004-02-05 16:05:04.0 +
--- ../../jakarta-slide/src/share/org/apache/slide/common/NamespaceConfig.java 2004-04-24 16:33:04.0 +0100
***
*** 266,278
/**
* Automatically create users.
*/
! protected boolean autoCreateUsers = false;
/**
* Roles implementation to be used for automatically created users.
*/
! protected String autoCreateUsersRole = slideroles.basic.UserRoleImpl;
// - Properties
--- 266,278
/**
* Automatically create users.
*/
! protected String autoCreateUsers = null;
/**
* Roles implementation to be used for automatically created users.
*/
! protected String autoCreateUsersRole = null;
// - Properties
***
*** 595,601
/**
* Is automcatic user creation active ?
*/
! public boolean isAutoCreateUsers() {
return autoCreateUsers;
}
--- 595,601
/**
* Is automcatic user creation active ?
*/
! public String getAutoCreateUsers() {
return autoCreateUsers;
}
***
*** 850,866
}
try {
! autoCreateUsers = Boolean.valueOf
! (config.getConfiguration(auto-create-users).getValue())
! .booleanValue();
} catch (ConfigurationException e) {
! autoCreateUsers = false;
}
try {
autoCreateUsersRole =
config.getConfiguration(auto-create-users-role).getValue();
} catch (ConfigurationException e) {
}
}
--- 850,865
}
try {
! autoCreateUsers = config.getConfiguration(auto-create-users).getValue();
} catch (ConfigurationException e) {
! autoCreateUsers = null;
}
try {
autoCreateUsersRole =
config.getConfiguration(auto-create-users-role).getValue();
} catch (ConfigurationException e) {
+ autoCreateUsersRole = null;
}
}
diff -rc ./src/share/org/apache/slide/content/ContentImpl.java ../../jakarta-slide/src/share/org/apache/slide/content/ContentImpl.java
*** ./src/share/org/apache/slide/content/ContentImpl.java 2004-02-26 11:31:01.0 +
--- ../../jakarta-slide/src/share/org/apache/slide/content/ContentImpl.java 2004-04-24 18:07:29.0 +0100
***
*** 41,46
--- 41,47
import org.apache.slide.security.Security;
import org.apache.slide.structure.ActionNode;
import org.apache.slide.structure.LinkedObjectNotFoundException;
+ import org.apache.slide.structure.ObjectAlreadyExistsException;
import org.apache.slide.structure.ObjectNode;
import org.apache.slide.structure.ObjectNotFoundException;
import
Re: patch for auto-create-users
Jamie Mortimore [EMAIL PROTECTED] writes: The user would be created if the getPrincipal method was called from within a transaction but the newly created user would not be setup with the correct role. For example it would create the user if you perform a PUT method with the new user but the user would not be set up with any roles. This meant the PUT method would fail with a permission denied error. Also it appeared that the newly created user was not created correctly. There was no creation date or revision information. To fix this I made the following changes: Firstly I stripped the code that was not working out of the SecurityImpl.getPrincipal method. This means getPrincipal will no longer attempt to create a new user under any circumstances. I added a createUser method to the Content interface and implementation, ContentImpl. You may decide this is not the right place for a create user method if Content is only supposed to handle more low level operations. In which case the functionality could be moved to the only place createUser is called from - AbstractWebdavMethod.run. I have been thinking about MacroImpl as the right place or a new helper for higher level user management. The createUser method takes 3 parameters: * root - The SlideToken to use to perform the necessary operations - this should have the credentials of a root user in order to perform the operations successfully. * userName - The name of the new user. * role - The role of the new user. Pass in null to create the user without any roles. Shouldn't this be a potentially empty list of roles? I modelled the createUser method around what I could gather was being done in the XMLUnmarsheller during creation of users at startup. The createUser method is only called from one place - AbstractWebdavMethod.run. I am assuming this is an entry point for all wedav methods. The first thing this method now does is: The servlet would need it too, if it wants to create a directory listing for a GET on a collection. I don't think the slideroles.basic.* classes are used anywhere anymore. Previously it looks like these classes were used to define the roles associated with users. But this no longer appears to be the case. The XMLUnmarsheller does not use them when creating users and the ACLSecurityImpl overwrites the previous implementation of hasRoles in SecurityImpl that did use them. Correct. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for auto-create-users
On Mon, 2004-04-26 at 10:52, Martin Holz wrote: I added a createUser method to the Content interface and implementation, ContentImpl. You may decide this is not the right place for a create user method if Content is only supposed to handle more low level operations. In which case the functionality could be moved to the only place createUser is called from - AbstractWebdavMethod.run. I have been thinking about MacroImpl as the right place or a new helper for higher level user management. Sounds good - I'll move the method(s) there. The createUser method takes 3 parameters: * root - The SlideToken to use to perform the necessary operations - this should have the credentials of a root user in order to perform the operations successfully. * userName - The name of the new user. * role - The role of the new user. Pass in null to create the user without any roles. Shouldn't this be a potentially empty list of roles? Potentially yes. I didn't add support for lists of roles as the previous version (if it had worked) didn't support it (not that that's a good reason not to add it). I was thinking about adding a set of methods along the lines of: addUser removeUser addRole removeRole addUserToRole removeUserFromRole I modelled the createUser method around what I could gather was being done in the XMLUnmarsheller during creation of users at startup. The createUser method is only called from one place - AbstractWebdavMethod.run. I am assuming this is an entry point for all wedav methods. The first thing this method now does is: The servlet would need it too, if it wants to create a directory listing for a GET on a collection. Are you saying there is a way webdav methods are called that do not go through AbstractWebdavMethod.run? Is there a more appropriate place to call the createUser method (eg at the start of WebdavServlet.service)? I'm going to be using slide on a project I'm working on at the moment and can devote some time to fixing any problems that would effect this project + any enhancements required. Would it be helpful if I provide a patch that includes the above against the latest cvs version of Slide? Obviously I don't want to spend time on another patch if someone else is already looking at integrating this functionality. Jamie. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for auto-create-users
Hi, I'd propose to add the methods regarding the user/role stuff to the Security-Interface and the SecurityImpl-class. There already are some methods regarding user/role management (hasRole()...) In general I think it would be better to have only one place (e.g. LDAP) where users are managed and give slide the ability to access the LDAP-user/roles. What if you add a user and auto-create it in slide. After that you grant a permission to this user and delete the user lateron? The user will not be deleted in slide as no auto-delete can be done. So you have an inconsistent user database where some users in slide exist that don't exist in your primary user store anymore. Adding your propsed methods is a good thing anyway as many users might need some simple methods to create users and add roles at slide api level. Regards, Daniel Jamie Mortimore wrote: On Mon, 2004-04-26 at 10:52, Martin Holz wrote: I added a createUser method to the Content interface and implementation, ContentImpl. You may decide this is not the right place for a create user method if Content is only supposed to handle more low level operations. In which case the functionality could be moved to the only place createUser is called from - AbstractWebdavMethod.run. I have been thinking about MacroImpl as the right place or a new helper for higher level user management. Sounds good - I'll move the method(s) there. The createUser method takes 3 parameters: * root - The SlideToken to use to perform the necessary operations - this should have the credentials of a root user in order to perform the operations successfully. * userName - The name of the new user. * role - The role of the new user. Pass in null to create the user without any roles. Shouldn't this be a potentially empty list of roles? Potentially yes. I didn't add support for lists of roles as the previous version (if it had worked) didn't support it (not that that's a good reason not to add it). I was thinking about adding a set of methods along the lines of: addUser removeUser addRole removeRole addUserToRole removeUserFromRole I modelled the createUser method around what I could gather was being done in the XMLUnmarsheller during creation of users at startup. The createUser method is only called from one place - AbstractWebdavMethod.run. I am assuming this is an entry point for all wedav methods. The first thing this method now does is: The servlet would need it too, if it wants to create a directory listing for a GET on a collection. Are you saying there is a way webdav methods are called that do not go through AbstractWebdavMethod.run? Is there a more appropriate place to call the createUser method (eg at the start of WebdavServlet.service)? I'm going to be using slide on a project I'm working on at the moment and can devote some time to fixing any problems that would effect this project + any enhancements required. Would it be helpful if I provide a patch that includes the above against the latest cvs version of Slide? Obviously I don't want to spend time on another patch if someone else is already looking at integrating this functionality. Jamie. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for auto-create-users
Jamie Mortimore [EMAIL PROTECTED] writes: Are you saying there is a way webdav methods are called that do not go through AbstractWebdavMethod.run? Is there a more appropriate place to call the createUser method (eg at the start of WebdavServlet.service)? I think, AbstractWebdavMethod.run is the right place. There is exactly one special case, where AbstractWebdavMethod is not called. This is a GET on a collection, which is handled by WebdavServlet on its own. I'm going to be using slide on a project I'm working on at the moment and can devote some time to fixing any problems that would effect this project + any enhancements required. Would it be helpful if I provide a patch that includes the above against the latest cvs version of Slide? Obviously I don't want to spend time on another patch if someone else is already looking at integrating this functionality. It wa somewhere on the bottom of my TOODO list. I would we happy if you send patches. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: patch for auto-create-users
Daniel Florey [EMAIL PROTECTED] writes: Hi, I'd propose to add the methods regarding the user/role stuff to the Security-Interface and the SecurityImpl-class. There already are some methods regarding user/role management (hasRole()...) This is not possible, since the methods need access to ContentImpl et. al. which are not available. Adding those helpers would create cyclic dependencies. In general I think it would be better to have only one place (e.g. LDAP) where users are managed and give slide the ability to access the LDAP-user/roles. This is definitely one way. It can be done right now, if you implement a LDAP store. However mapping LDAP groups to slide groups can be a real pain. As a side note slide has currently no concept of a read only store, which would be really useful here. What if you add a user and auto-create it in slide. After that you grant a permission to this user and delete the user lateron? The user will not be deleted in slide as no auto-delete can be done. So you have an inconsistent user database where some users in slide exist that don't exist in your primary user store anymore. Adding your propsed methods is a good thing anyway as many users might need some simple methods to create users and add roles at slide api level. Regards Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
