/Firstly, did you use a "fedora.server" -style URL for your reference to the
policy datastream? If so, that might circumvent the external DS policies,
which could cause some of this odd behavior./
No, the reference URLs aren't in the fedora.server style
they're like http://123.456.78.90:port/fedo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel--
We discussed this problem a bit on the Fedora committers' call this morning,
and here are some more things to try:
Firstly, did you use a "fedora.server" -style URL for your reference to the
policy datastream? If so, that might circumvent
/Can you retrieve col:policy/POLICY directly? If you try changing the ID of
that datastream to something like "COLLECTIONPOLICY" (or something shorter)
does your configuration work?/
It is getting interesting now. I tested the following scenarios:
a) The policy is stored in col:policy/POLICY and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
By "recursion" I mean that I'm wondering (and this is just off the top of my
head) if:
1) Your data objects are guarded by col:policy/POLICY.
2) Upon a request for one of your data objects, the policy engine attempts to
retrieve col:policy/POLICY.
Thank you for your reply!
As you have suggested I tried to refer from several objects to a policy that
is stored in another non-repository location. The result is, that it worked
fine.
I can't see a recursion problem as the policy in col:policy is internal XML.
What do you mean with "setting the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This may be a simplistic idea, but are the policies on the col:policy object
set so that it can effectively be referenced from the other objects? In other
words, might the 401 be occurring because col:policy/POLICY is off-limits? Or
do you have a re
Dear all,
with our latest ingest we tried to change our object related XACML policies
from Internal XML (X) to External Reference (E) so we could change the
policy in the source object col:policy in order to change all the policies
that refer to this one.
But unfortunatley we encounter massive p