Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of fmeschbe@adobe.com designates
 64.18.1.191 as permitted sender)
From: Felix Meschberger <fmeschbe@adobe.com>
To: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Date: Fri, 15 Mar 2013 08:01:55 +0000
Subject: Re: Getting a value by its data identifier
Thread-Topic: Getting a value by its data identifier
Thread-Index: Ac4hU1wqux/WN4JHSVKOrbqfXsHnUg==
Message-ID: <B9A66ED4-EA34-44BB-B8A2-49337CECDE57@adobe.com>
References: <8F5B0586-FB96-4296-9310-576FFF0D30F8@adobe.com>
 <4C552DC4-C603-4409-8AFD-E9FB8909036B@adobe.com>
In-Reply-To: <4C552DC4-C603-4409-8AFD-E9FB8909036B@adobe.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

Am 12.03.2013 um 15:02 schrieb Alexander Klimetschek:

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

I would prefer a SecurityException, but JCR has a notion of "no access look=
s 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 requ=
ire a user with wide permissions

+1

We could use a repository level permission like we have to workspace creati=
on.

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

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

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

I would expect such a content identity to be "globally unique" and internal=
ly handled by the repository such that roundtripping between getContentIden=
tity and getValueByContentIdentity can be guaranteed (provided access contr=
ol allows for it.

Regards
Felix

>=20
> Cheers,
> Alex
>=20
>=20


--
Felix Meschberger | Principal Scientist | Adobe