jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Getting a value by its data identifier
Date Fri, 15 Mar 2013 08:01:55 GMT

Am 12.03.2013 um 15:02 schrieb Alexander Klimetschek:

> On 12.03.2013, at 12:32, Felix Meschberger <fmeschbe@adobe.com> wrote:
>> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method would
allow for round tripping the JackrabbitValue.getContentIdentity() preventing superfluous binary
data copying and moving.
> The idea sounds good to me :-) (Disclaimer: discussed this with Felix f2f before)
>> Questions:
>> (c) Can we and if yes, how can we control access ?
> It's a bit tricky, and I think the best way to do it is:
> - by default no access at all (getValueByContentIdentity() returns null aka not found)

I would prefer a SecurityException, but JCR has a notion of "no access looks the same as non-existing",
so an ItemNotFoundException would probably be thrown in this case (due to JCR throwing an
exception if something does not exist instead of just returning null).

> - have a special privilege for this feature, that you only want to enable for users that
need this feature
> - because such a repository-wide optimization feature generally does require a user with
wide permissions


We could use a repository level permission like we have to workspace creation.

> - nice to have: avoid that the content ID is a hash of the binary, so that an attacker
(who already go the above privilege) still cannot infer existence of a binary he knows; but
then he might have enough read & write access already, as a user with that permission
is likely to have broad rights, as for copying things over from one instance to another requires

We don't do such "security by obscurity" things for regular path and node ID acces. So we
might not want to try it here. Rather we should provide proper access control on access.

>> (d) What else ?
> This is practically only about Binaries and the FileDataStore, but the JackrabbitValue.getContentIdentity()
is generic across all value types. If there might be such a store for other properties in
the future, the content id must uniquely identify that store (e.g. value type) as well.

I would expect such a content identity to be "globally unique" and internally handled by the
repository such that roundtripping between getContentIdentity and getValueByContentIdentity
can be guaranteed (provided access control allows for it.


> Cheers,
> Alex

Felix Meschberger | Principal Scientist | Adobe

View raw message