request authorization to remove permissions
delete content
revokePermissions as previously authorized
Probably easier to just delete at the store level unless there's a more general reason to be able to request authorizations up front in a transaction (and I can't think of a good one right now, though some form of cached effective permissions might make this route easier ...)
Jim
----- Original Message ----- From: "Oliver Zeigermann" <[EMAIL PROTECTED]>
To: "Slide Developers Mailing List" <[EMAIL PROTECTED]>; "Jim Myers" <[EMAIL PROTECTED]>
Sent: Tuesday, October 19, 2004 1:16 PM
Subject: Re: Suspicious code in MacroImpl deleteObject
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]
