On 12.03.2013, at 12:32, Felix Meschberger <fmesc...@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) - 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 - 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 that > (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. Cheers, Alex
