Wouldn't it be possible to first delete the content and node information and then delete permission and locking *directly* on the store that contained the object? Without going through the helpers?
Oliver On Tue, 19 Oct 2004 13:12:06 -0400, Jim Myers <[EMAIL PROTECTED]> wrote: > Oliver, > > Not sure it applies here, but I remember looking around one time and > discovering that removing permissions ends up checking to see if the object > exists, so if they aren't removed before the object is deleted, you get > errors. revokePermission() has a call to checkCredentials(token, object, > ...) in it. For slide 1, I think we kludged and silently caught the > ObjectNotFoundException caused by Macro.delete(). > > With a quick look in MacroImpl, I'm don't see any way that a security > setting on the node being delted is getting checked either, but a fix will > probably have to do more than just remove content and then the > permissions... > > Jim > > > > > ----- Original Message ----- > From: "Oliver Zeigermann" <[EMAIL PROTECTED]> > To: "Slide Developers Mailing List" <[EMAIL PROTECTED]> > Sent: Tuesday, October 19, 2004 11:32 AM > Subject: Re: Suspicious code in MacroImpl deleteObject > > On Tue, 19 Oct 2004 16:44:36 +0200, Stefan L�tzkendorf > <[EMAIL PROTECTED]> wrote: > > > > Versions are maintained at the version history resource I think. That > > one of the things im bewildered again and again (:-) > > If you put a resource under version control and check it in some times, > > you will not found any aditional revisiondescriptor at the resource but > > at the history resource. So I think (webdav) versions are NOT removed. > > (Multiple revisions I have ever observerd when removing the history > > resource, i.e. the collection where the versions are stored) (Thats why > > think the webdav versioning and the slide versioning are designed under > > different views, and something could be improved we only want to support > > webdav) > > Right, forgot about that... > > > The other point looks weired too. First locka and permissions are > > removed, and than content and the node are removed. The checks in > > ContentImpl.remove and StructureImpl.remove seem to be made effectless. > > But why we dont observe strange security violations? > > I guess because inherited security setting apply here. It is just > local settings that are removed. Still, seems to be just wrong to me. > > Oliver > > --------------------------------------------------------------------- > 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]
