Hi Oliver, With the auto-create-users functionality enabled the SecurityImpl.getPrincipal method would try to create a user in slide if the current user was not set up in slide.
There were a couple of problems with this. Firstly not all webdav methods require a transaction but the creation of a user does require a transaction. So, for example, if you have auto-create-users enabled and attempt a GET with a user not set up in slide the getPrincipal method would throw an exception indicating a transaction is required. 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. 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. 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: if auto-create-users has been specified in the configuration then - try to retrieve the principal using Security.getPrincipal - if the principal does not exist then -- create the principal using the createUser method in a transaction The parameters passed to the createUser call above are as follows: * root - A new SlideToken with the credentials of the user specified in the auto-create-users configuration parameter - must be a root user otherwise an exception will be thrown. * userName - The name of the user to create. * role - The role specified in the auto-create-users-role configuration parameter, null if this is not specified in the configuration. Previously NamespaceConfig expected a boolean value for the auto-create-users parameter. It now expects a string. To reflect this the isAutoCreateUsers method has been renamed getAutoCreateUsers and returns the name specified in the auto-create-users parameter. It defaults to null so will return null if auto-create-users is not specified. Previously NamespaceConfig expected a class name for the auto-create-users-role parameter. It defaulted to "slideroles.basic.UserRoleImpl". It now expects the name of a role and defaults to null. 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. Hope this helps you evaluate the patch. Let me know if anything is not clear. Thanks, Jamie. On Mon, 2004-04-26 at 08:54, Oliver Zeigermann wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
