In general, it seems that using the original request context (or a derivative) is the "right" thing from a functional perspective. And in the short term, I guess I'm not concerned about breaking existing code out there that depends on the current getChecksum and compareChecksum methods, because people depending on classes in that package to stay static should...absolutely not be.
Longer-term, I think we ought to consider much simpler "data transfer objects" (like fcrepo-dto-core's Datastream class[1]), aka "value objects" at this level, and keep the computation of checksums and other such functionality at a higher level in the server code. I think it would be great if someday people *could* depend on these "low level" classes in their own projects, without necessarily bringing a whole running Fedora server with them...for a lot of reasons. Reasonable unit testing being one. [1] http://cwilper.github.com/fcrepo-misc/apidocs/com/github/cwilper/fcrepo/dto/core/DatastreamVersion.html#contentDigest() On Thu, Mar 22, 2012 at 10:40 AM, Benjamin Armintor <armin...@gmail.com> wrote: > Yes, I could also use the backend security information, but that would > require injecting that module into the Datastream objects. It's all a > question of how dramatic a change we can tolerate for this release. > This is not an alternative to Chris's suggestion, by the way, but an > extension: Require a context and also make that context appropriate > for internal user. > > On Thu, Mar 22, 2012 at 10:37 AM, aj...@virginia.edu <aj...@virginia.edu> > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I'm with Chris on this, but I'd add that it might be appropriate to use a >> separate request context which is initialized as a duplicate of the >> original. This is because the "subrequest" is acting against a very >> different set of resources (filesystem resource) than the origina, and it >> might eventually be appropriate to have the ability to modify the >> "subrequest" before using it (for example, with backend authentication >> information). >> >> - --- >> A. Soroka >> Software & Systems Engineering :: Online Library Environment >> the University of Virginia Library >> >> On Mar 22, 2012, at 10:30 AM, Chris Wilper wrote: >> >>> Hi Ben, >>> >>> Is there any possibility of using (or mimicking) the original request >>> context? For example, if the file needed to be retrieved as a result >>> of doing an addDatastream request, could the request context of the >>> addDatastream request be used? >>> >>> - Chris >>> >>> On Tue, Mar 20, 2012 at 11:00 AM, Benjamin Armintor <armin...@gmail.com> >>> wrote: >>>> Hello, >>>> I've written up some tests and arrived at several possible >>>> approaches for https://jira.duraspace.org/browse/FCREPO-787, and >>>> wanted to solicit some input about which is preferable. >>>> >>>> The Problem: In short, Fedora often cannot checksum external >>>> datastreams (type E) with file uris (dsLocation='file://...') because >>>> of a XACML prohibition. This is because the the action for retrieving >>>> file content is checked as part of the API-M interface, but the >>>> security context has no request attributes. This runs afoul of the >>>> policies many installations have restricting API-M actions to >>>> localhost, or other addresses specified in a policy (and, in fact the >>>> default policy). >>>> >>>> Possible solutions: >>>> 1. Change the default XACML policy restricting API-M to allow the file >>>> retrieval actions without a client IP. This may be a difficult change >>>> to communicate to installations that are overriding that policy. >>>> >>>> 2. Mimic a request context for the file retrieval action. This >>>> requires the least configuration change, but raises the question of >>>> what attributes should be included besides client IP. Should there be >>>> a fedoraRole, and if so, which? Should it use the internal user >>>> information? I think the trajectory of FCREPO development has been >>>> towards less use of internal users, but it would allow more elaborate >>>> policy specification for retrieval of file resources. >>>> >>>> 3. Use a different API designator for internal actions. This would >>>> address the bug without changes to existing policies, but may obscure >>>> what policies must be composed to restrict a given action. >>>> >>>> Thoughts? Additional solutions? >>>> >>>> - Ben >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF email is sponsosred by: >>>> Try Windows Azure free for 90 days Click Here >>>> http://p.sf.net/sfu/sfd2d-msazure >>>> _______________________________________________ >>>> Fedora-commons-developers mailing list >>>> Fedora-commons-developers@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >>> >>> ------------------------------------------------------------------------------ >>> This SF email is sponsosred by: >>> Try Windows Azure free for 90 days Click Here >>> http://p.sf.net/sfu/sfd2d-msazure >>> _______________________________________________ >>> Fedora-commons-developers mailing list >>> Fedora-commons-developers@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> >> iQEcBAEBAgAGBQJPazlHAAoJEATpPYSyaoIk3z0H/RdDdShBVQ5c4oescb3hrhBe >> ULQ2g1Iug/l1CWidx7uVSLig1f6wiUJtBpowlOZ4sEt18kxuzqq6AnC1Cqk71TbX >> tLa3dBPzShHLza3yi/QH9AVBWm9UGoXWrapwwx845XlZswZexG1+q3KZ/BMJvwQK >> pLgfnwrwKF/qXOyWvkYPqVlEqLXkef16PnsaZrDHCRAJdc7VOpTaNskg/YKXVO5C >> OzZHpABe2uZ04GOSYibuCB/KMhty+HoPuk6sVJmpJ5k2N6iR8H578D0AW5sgc1FL >> 4eQOhdN7SrqbiBxXYlty7qnD6f0pJrbuxWRT1Nf4gd22Tjoo1PszuBB79/38HHM= >> =5ium >> -----END PGP SIGNATURE----- >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Fedora-commons-developers mailing list >> Fedora-commons-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Fedora-commons-developers mailing list > Fedora-commons-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
