jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3534) Add JackrabbitSession.getValueByContentId method
Date Wed, 24 Apr 2013 11:55:17 GMT

    [ https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640355#comment-13640355
] 

Thomas Mueller commented on JCR-3534:
-------------------------------------

I was chatting with Tommaso Teofili about the basic data structures, features, and security
protocols. There are still a few open questions regarding the API, but here what we have so
far:

DataIdentifier: The (unencryptged and unsigned) identifier of the binary, as already used
by the Jackrabbit DataStore. Please note it could be a reference to a file, or, for small
binaries, contain the data itself.

DataStoreSecret: a secret value that needs to be configured to be the same value in all repositories
that share the same physical data store. It is used as the basis to encrypt and decrypt the
DataIdentifier, and to sign and verify the signature. This could be a configuration parameter
of the DataStore element in the repository.xml, but then we would probably need to change
each DataStore implementation were we want support for the new feature? To avoid that, should
be add a new element to the repository.xml? Not sure what is the easiest.

BinaryReferenceMessage: The encrypt DataIdentifier, the random salt, the expiry time. Plus
the signature of all of that. The encryption key for the DataIdentifier is the (SHA-1) hash
of the random salt combined with the DataStoreSecret (this is to avoid re-using the same encryption
key for all BinaryReferenceMessages). The random salt is per message. The expiry time is the
maximum system time up to when to accept the BinaryReferenceMessage (same as for time limited
S3 URLs), for example the system time the message was generated plus 2 hours or so. The signature
is the HMAC of the rest of the message, with the DataStoreSecret as the key. To simplify development/support,
the message should readable, for example JSON or an URL. Example (shortened): "{encryptedDataId:0123456789abcd,
salt:1234, expiry:3456, signature:4567}". This will also allow to change the algorithms in
the future. For now, we could use the following algorithms / formats: 128 bit DataStoreSecret
and salt (generated with a SecureRandom); AES-256 encryption / AES-CTR mode; expiry: milliseconds
since 1970 UTC; signature: HMAC-SHA-1.

                
> Add JackrabbitSession.getValueByContentId method
> ------------------------------------------------
>
>                 Key: JCR-3534
>                 URL: https://issues.apache.org/jira/browse/JCR-3534
>             Project: Jackrabbit Content Repository
>          Issue Type: New Feature
>          Components: jackrabbit-api, jackrabbit-core
>    Affects Versions: 2.6
>            Reporter: Felix Meschberger
>         Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global data store
to prevent sending around and copying around large binary data unnecessarily: We have two
separate Jackrabbit instances configured to use the same DataStore (for the sake of this discussion
assume we have the problems of concurrent access and garbage collection under control). When
sending content from one instance to the other instance we don't want to send potentially
large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from JackrabbitValue.getContentIdentity().
The receiver would then check whether the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
>     Value v = session.getValueByContentIdentity(ci);
>     Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
>     // unknown or invalid content Identity
> } catch (RepositoryException re) {
>     // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method would allow
for round tripping the JackrabbitValue.getContentIdentity() preventing superfluous binary
data copying and moving. 
> See also the dev@ thread http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message