XACML emabrgo policy, can still access PDF

Project:RUcore dlr/EDIT
Category:bug report

Created an XACML embargo policy for rutgers-lib:24360 on lefty64. Was still able to access the PDF through a tmp link that is created:

<a href="http://lefty64.scc-net.rutgers.edu/dlr/TMP/rutgers-lib_24360-PDF-1.pdf" title="http://lefty64.scc-net.rutgers.edu/dlr/TMP/rutgers-lib_24360-PDF-1.pdf">http://lefty64.scc-net.rutgers.edu/dlr/TMP/rutgers-lib_24360-PDF-1.pdf</a>

I think either some cleanup needs to be done or even better, the script that creates the TMP links needs to smarten up and not use TMP links.



Status:active» fixed

fixed, please test


Status:fixed» active

Still can access the PDF using the TMP link after invoking an XACML policy.


Assigned to:jgeng» triggs


The current PDF link in TMP needs to be deleted manually. In 5.1 purging (before re-adding) the datastream will take care of a situation like this, but for now it requires Dave. Since the embargo is in place, no other PDF link will be able to be created in TMP. Any dlr/EDIT access will be through ItemIndex using getfedoraapia, which does not use links in TMP.


Does the workflow process support and this manual intervention? Will the person applying the XACML policy be responsible for contacting Dave with the appropriate information or is that someone else? I think this interim solution needs to be documented and disseminated to the group at large.


If the xacml policy is put in as soon as the object is ingested, this should not happen. The object in question was put in long before - by accident? or did the student suddenly decide it needed the embargo? - in any event, it was not a normal situation. I think after the new release, the procedure should probably be:
1) to save the datastream,
2) to purge the datastream (and any links along with it),
3) to put in the policy, and
4) to re-enter the datastream.


I think embargo's might be placed after the fact so cleanup will need to happen to ensure the policy enforcement actually means every avenue to accessing the file has been addressed. While I am not advocating for a code change for this release, at the very least this manual cleanup needs to be identified as a step in application of a policy and communicated.


The manual cleanup is indeed needed now for any object which has at one time or another been displayed. I have a function now in full object access that allows deletion of selected symlinks without the need to purge the datastream itself. This should provide all the functionality we need for now.


Google search is still redirecting to the TMP symlink and the users are able to access the PDF.



Has this been resolved? If so, please close this bug, if not, move it to R5.2.



Version:5.1» 5.1.1


Assigned to:triggs» Anonymous
Status:active» closed

If a link exists in TMP directory, the Purge TMP datastream link in dlr/EDIT will delete the link in TMP.

Back to top