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]
