I saw the Security implementation that does this when looking through the source code. Won't this create nodes for my users and roles in my NodeStore? Since I am using an existing file system to back my NodeStore this would not be an option for me.
Thanks, Alon On Wed, 15 Sep 2004 13:29:44 +0530, Ritu Kedia <[EMAIL PROTECTED]> wrote: > Alon, > > Your problem could be solved by turning auto-create-user on in domain.xml > (<auto-create-users>true</auto-create-users>) > This would ensure that if the principal is not already there in slide db > then one would be created prior to executing the requested method. > > Hope this helps. > > Regards, > Ritu > > > > -----Original Message----- > From: alon salant [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 14, 2004 10:06 PM > To: Slide Users Mailing List > Cc: [EMAIL PROTECTED] > Subject: Re: Problem disabling slide authorization > > So after letting this sit for just a little bit, it strikes me that > this may be considered a bug in SecurityImpl (or the calling Method > implementations). The Methods are calling getPrincipal() so that they > can set the owner metadata in the node being created. When security is > off but webapp security is on, there is a Principal in the > CredentialsToken but it does not exist in the store. So you get an > ObjectNotFoundException. > > If SecurityImpl finds a Principal in the CredentialsToken but not in > the NodeStore, why not return a SubjectNode with the principal name as > the path? Or do this if slide security is disabled? > > Alon > > On Tue, 14 Sep 2004 00:24:16 -0700, alon salant <[EMAIL PROTECTED]> wrote: > > With a little digging, I appear to have a solution. > > > > It looks like you can set your own implementation of Security in > > Domain.xml with <parameter name="acl_semantics"></parameter>. > > > > I created an AllowAllSecurityImpl that does its best to be okay with > > everything. The only method I really implemented is > > getPrincipal(SlideToken token) which returns SubjectNode.UNAUTHORIZED > > if there is no user principal in the SlideToken, or a SubjectNode with > > the principal name as the path if there is a principal. > > > > So I configure my domain to load it with: > > > > <configuration> > > <parameter > name="acl_semantics">org.apache.slide.store.file.AllowAllSecurityImpl</param > eter> > > </configuration> > > > > > http://cvs.sourceforge.net/viewcvs.py/photospace/slidespace/WEB-INF/src/org/ > apache/slide/store/file/ > > > > Seems to work for me. Any comments or gotchas I may have missed? > > > > Alon > > > > > > > > > > On Mon, 13 Sep 2004 23:41:17 -0700, alon salant <[EMAIL PROTECTED]> wrote: > > > When working on SimpleFileStore, it was easy to disable Slide security > > > by setting > > > > > > org.apache.slide.security=false > > > > > > in slide.properties. > > > > > > However, I do want to be able configure basic webapp security using > > > security constraints on paths and HTTP methods. But I do not want to > > > manage users and roles within slide. > > > > > > So I have slide configured with security=false, SimpleFileStore, > > > TransientSecurityStore, and TransientLockStore for my store > > > implementations, all user and role definitions removed from Domain.xml > > > and basic auth configured in my web.xml for the path to the webdav > > > servlet. > > > > > > With this config, I can connect via webdav, log in and browse. > > > > > > However, I cannot create files or folders, copy, move, delete.... > > > > > > The problem that I am running in to is that Methods (MkcolMethod for > > > example), still try to authorize the current principal. If the > > > principal is null, things work fine b/c SecurityImpl returns > > > SubjectNode.UNAUTHENTICATED and slide lets this continue. However, if > > > the principal is not null (it is not when the webapp makes the user > > > log in), SecurityImpl.getPrincipal( ) tries to retrieve an object for > > > that user resulting in an ObjectNotFoundException. > > > > > > This looks like hard behavior to change (unfortunately). > > > AbstractWebDavMethod creates the SlideToken with the user principal in > > > run( ) using req.getUserPrincipal(). > > > > > > I haven't traced through the other methods to see if/how the user > > > principal is used. It looks like copy/delete/put/move/mkcol (at least) > > > all have issues related to this. > > > > > > Any thoughts? What I am trying to do seems like a pretty common use > > > case. Is there a good way to address this need? I'm hoping I've missed > > > something simple. > > > > > > Alon > > > > > > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
