Re: [jira] Commented: (SLING-249) Allow mapping nodes to internet domains

["Roy T. Fielding" <fi...@gbiv.com>]

On Nov 27, 2008, at 4:25 AM, Felix Meschberger wrote:
> Roy T. Fielding schrieb:
>> But that is backwards, in my opinion.  We should have a node called
>>
>>    /content/beispiel
>>
>> that says it is a hard link (alias) for
>>
>>    /content/sample
>>
>> because sample may be a fixed node type that is either non-modifiable
>> or limited in its allowed properties.  Does JCR support hard links
>> natively in JSR 283?  If not, we can use sling:alias.
>
> I defined a mixin node type sling:ResourceAlias, which provides the
> sling:alias property and which may be assigned to the resoure which
> would take the property.
>
> There are catches with each solution:
>
> My solution, which you call "backwards" is harder to implement in the
> resolver since we have to scan the children for any property set as
> expected. On the other hand it is easier to manage as a property of  
> the
> resource to which it applies and it moves together with the resource.
>
> Your solution (lets call it "forward") is simpler to implement in the
> resolver, but we would have to check on each access whether there is a
> property set on the resovled resource. But managing the value is more
> complicated because when moving the target (move, delete, copy) the
> alias still "points" to the old location thus resolution will be  
> failing.
>
> I tend to prefer the "backwards" way.

I should have mentioned that the reason it is backwards is because
resources are expected to have hierarchical names that may be governed
by access control.  Names under a given level (collection) are expected
to be allocated through permissions on that level, just as you need
write permission on a filesystem directory in order to change the
filenames within it.  That access control may be delegated down to
individual nodes.  In other words, the ownership of a child node
does not imply permission to create sibling nodes/aliases, which
makes the "backwards" way a minor security hole.

For example, say I have a hierarchy like

    path              owner
    ===============   =======
    /students/        (admin)
         |----mike    (mike)
         |----kim     (kim)
         `----roy     (roy)

and then kim graduates.  The admin owner of /students/ decides to delete
/students/kim because the association is gone, and has implemented some
default code somewhere that says a "not found" under students will
result in a 410 (Gone) message.

The backwards scheme will allow any student to recreate /students/kim
as an alias to their own (authorized) page.  Likewise, students can
create their own fun aliases, like "bestinclass" "sir_farts_a_lot", etc.
And, while that's just a silly example, the same would be true of
multiple merchants sharing a single host, or rival dealerships within
the same manufacturer's information space.

....Roy