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
