jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: BlobFactory (was Re: svn commit: r1401571 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/api: BlobFactory.java Root.java)
Date Wed, 24 Oct 2012 09:01:53 GMT
hi michael

>>> The consequences of not doing so is, that there is no way to create
>>> blobs through the Oak API which are immediately streamed down to the
>>> Microkernel.
>> yes... i know :)
>> don't get me wrong, i am not opposed to that in general.
>> but there are some open issues associated with that, which i
>> would like us to clarify before we finalize the API.
> Since we have to address these issues anyway because we have the same
> problem with ValueFactory.createBinary(), I'd rather also keep a means
> for creating Blobs in the Oak API. Otherwise the API wouldn't be
> complete and other bindings would have to come up with their own plugins
> just to write binaries.

well... valuefactory.createBinary uses the same blob-factory as
it used the contentsession#createBlob before. i just wanted to
reflect the fact that binary-creation is totally separate from
creation of regular content in the API. in particular i don't
see why a valuefactory instance should have access to the
complete feature-set exposed by the Root when it only needs
to create binaries. but that's obviously a matter of taste.

>> yes, that's correct... but it doesn't mean that we shouldn't
>> think about the consequences of having such a feature.
> Right. I just wanted to check whether there where considerations re.
> this earlier and what these where. But maybe the whole thing only came
> up through having the BlobFactory that explicitly in the API.

no, that's not the case.
i already asked for being very conscious/careful about security issues
with respect to that binary-store a year ago. i would have
added the same comment/TODO to any other createBlob method...

>> what happens if the adding/changing a binary property fails due
>> to lack of permissions or due to conflicts or value constraint
>> violations or some other custom value-validation? i think that we
>> need the ability to revert the changes made to the binary-store
>> in such cases...
>> if we don't have that ability everyone having a Root/ContentSession
>> at hand (even if it was a read-only session) could dump any kind
>> of binaries into the repository. that doesn't make sense to me
>> and looks like a critical security issue... remember o.html? IMO
>> it's that kind of troubles we are looking for when not having any
>> means to control who and what is written to the binary store and
>> not having the ability to revert changes if the overall commit
>> fails.
> Currently the data store garbage collector of the Microkernel cleans
> unreferenced binaries out after some time. If we want to have more
> explicit control of the life cycle for binaries, we'd need to have
> support for this from the Microkernel.

basically i don't care how we implement it. but i think it's
crucial that we have the ability to control it... immediately
persisting binary-values without being able to enforce any kind
of validation or permission checks and ultimately reverting back
the changes is IMO not acceptable.

kind regards

> Michael
>> kind regards
>> angela

View raw message