jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Versionable paths
Date Thu, 31 Oct 2013 21:55:29 GMT

but you don't gain anything when you store the path of the versionable
node with the version. the evaluation will be excuted against the
current persisted effective permissions present on the versionable
node referred to by that path not the state when it was 'private'.

IMO the most common case is that a given node is checked-in multiple
times -> you would always get the latest effective permissions on the
versionable node :-)

there might be cases where the node is moved around and checked-in
in the mean time -> if the versionable location does no longer exists
you wont get any reliable permission result when evaluating
the original path... and in addition it will be very hard to understand
how the effective permissions are being calculated on version content.
in the worst case the result will be quite arbitrary as the original
'private' permission is gone and you just get the inherited permissions
(most probably not what you wanted if i try to figure out what use
case you are referring to).

so, if you really wanted to have the permissions effective at the time
the version was created you have to compile the effective permission
for the version, each property and each item contained in the frozen
node into the version store and then do that for all workspaces containing
a corresponding item for each and every of these items. that's what
why i think it's not feasible :-) for sure it will not work properly
if you just store the path of the versionable node with the versions.

kind regards

On 10/31/13 6:36 PM, "Tobias Bocanegra" <tripod@apache.org> wrote:

>On Thu, Oct 31, 2013 at 2:03 AM, Angela Schreiber <anchela@adobe.com>
>> hi
>> if i remember correctly the move case you mentioned below is
>> covered by the commit hook (see VersionablePathsTest). if there
>> are cases that don't work properly i would be glad if you could
>> provide add a test case (patch for the fix is optional).
>No, this is not the issue. The main problem of the versioning is, that
>the versionable path is not recorded when creating a version. this is
>IMO a flaw in the spec. In CQ we added this information in order to be
>able to restore a deleted node. So I was happy to learn that oak now
>stores this information - but as I mentioned, on the wrong node.
>> as far as the location of the versionable path is concerned
>> i am not convinced that moving it the versions will add any
>> benefit. my plan was to bind accessibility of the whole
>> versionhistory associated with a versionable node to the
>> permissions enforced on that very node in a given workspace. so,
>> in other words the accessibility may change if the effective
>> permissions change for that node (by changing the ac content
>> or by moving around the node or any of it's ancestors).
>ok, so this is a different use case and does not solve the problem I
>mentioned above. however, moving a node to a different location might
>also change it's accessibility, and it's questionable if this is bound
>to the version history or the version itself.
>* you have node "/public/A" that you version, in V1.0,
>* and then move to "/private/A" that you version, in V2.0.
>* and then move it back to "/public/A" and version V3.0
>assuming the the versionable paths still exist when accessing the
>versions, I would assume that the versioned document V2.0 is still
>private, and 1.0 and 3.0 are public.
>> i guess what you intended to achieve by moving it to the
>> versions themselves is to version the effective permissions
>> themselves...
>> but that would not require moving the paths
>> information to the version but rather copying the complete
>> effective permissions to the version including all effective
>> permissions present to the whole subtree that is copied to
>> the version node. that's IMHO not feasible.
>why not? :-)
>> another disadvantage of moving it to the version information
>> is that you can't determine the accessibility of the version
>> history node. i had a similar issue when it comes to the
>> intermediate nodes the make up the structure of the version
>> storage and didn't find a satisfying solution.
>I don't think that the version history node itself is of much value.
>you could guess the existence of a node with the respective UUID
>(which is encoded in the VH name) but this is IMO not a security
>problem. or you can use the versionable path recorded in the last
>version to calculate the permissions for the version history.
>> and last:
>> you are right regarding collisions in the workspace name. but
>> i would suggest that we just escape the name.
>> as far as renaming/removing workspace is concerned: renaming is
>> not supported by JCR afaik. creating new workspace as well as an
>> existing workspace (once we actually support multi-workspace setup)
>> could be covered by the corresponding commit hook, couldn't it?
>regards, toby
>> On 10/30/13 11:52 PM, "Tobias Bocanegra" <tripod@apache.org> wrote:
>>>oak now has rep:VersionablePaths which record the paths (per
>>>workspace) of the versionable node.
>>>I think this is wrong to store this on the nt:versionHistory node,
>>>since a node can be moved in between checkins. so I think it should be
>>>recorded on the nt:version node.
>>>I also find it dangerous to just use the workspace name as property
>>>name for the path, as it makes it harder to list the paths, if ever a
>>>workspace is removed or renamed (not that this is supported). also, it
>>>does not work with "funny" workspace names, such as: "jcr:uuid" :-)
>>>I suggest the following structure:
>>>/jcr:system/jcr:versionStorage/..../ [nt:versionHistory]
>>>  /1.0 [nt:version]
>>>    /rep:versionablePaths
>>>        + workspace1name "/path/..."
>>>        + workspace2name "/path/..."
>>>        + workspace3name "/path/..."
>>>OR a MV value:
>>>/jcr:system/jcr:versionStorage/..../ [nt:versionHistory]
>>>  /1.0 [nt:version]
>>>    + rep:versionablePaths [
>>>           "workspace1name/path/",
>>>           "workspace2name/path/",
>>>           "workspace3name/path/"
>>>       ]
>>>Regards, Toby

View raw message