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
