Failure to push datastreams when object has XACML policy

[bondjimbond]

I'm trying to push a large batch of datastreams. CRUD fails whenever it hits an object with XACML "view" restrictions - even if I include -u 1 in my Drush command, and user 1 has explicit permissions for the object.

Full error text:

WD islandora: Failed to modify datastream MODS from trail:1721code:  [error]
404message: Not Found
WD php: RepositoryException: Not Found in                            [error]
RepositoryConnection->parseFedoraExceptions() (line 229 of
/var/www/html/drupal7/sites/all/libraries/tuque/RepositoryConnection.php).
Cannot modify header information - headers already sent by (output   [warning]
started at /opt/drush/includes/output.inc:38) bootstrap.inc:1499
RepositoryException: Not Found in RepositoryConnection->parseFedoraExceptions() (line 229 of /var/www/html/drupal7/sites/all/libraries/tuque/RepositoryConnection.php).
Drush command terminated abnormally due to an unrecoverable error.   [error]

Not only does the datastream fail to get pushed, but the entire batch is stopped - the command stalls out, and subsequent datastreams in the list are not pushed.

[bondjimbond]

Further investigation: Despite the error reported, the object that causes the Drush failure actually does get its new datastream pushed, but it stops the rest of the flow. The MODS gets modified, but it fails to generate the accompanying DC. See screenshot - the number of versions should match:

[mjordan]

@bondjimbond does the object in question have "Enable XACML Restrictions on DSIDs and MIME types" enabled?

[bondjimbond]

No, just viewing.

[mjordan]

To confirm, it's the MODS datastream you are pushing up, correct?

[bondjimbond]

Yep!

[mjordan]

I can't replicate this behavior. Here's my object's policy:

And here is the output when I push a MODS ds with CRUD:

vagrant@islandora:/var/www/drupal/sites/all/modules$ drush islandora_datastream_crud_push_datastreams --user=admin --datastreams_mimetype=application/xml --datastreams_source_directory=/tmp/pushtest --datastreams_crud_log=/tmp/crud.log
You are about to push datastreams to objects in your repository. This will create new versions of the datastreams, or create new datastreams if none exist. Do you want to want to continue? (y/n): y
Do you want to update each object's DC datastream using the new MODS? (y/n): y
MODS datastream pushed to object objtest:181                                                                                                                        [ok]
DC datastream for object objtest:181 regenerated from MODS                                                                                                          [ok]
vagrant@islandora:/var/www/drupal/sites/all/modules$ 

Can you see anything I am missing in order to replicate the problem?

[bondjimbond]

Weird. This is the POLICY I have for one of the objects:

CRUD is up to date; I can't fathom why XACML would be a problem in my environment but not yours.

[mjordan]

I'll add some non-admin users/roles and try again.

[mjordan]

I added a non-admin user to the allowed list, pushed, success. I then removed the non-admin user and pushed, also success. I also pushed MODS datastream for other objects in same run of CRUD, also success. If you can think of any other permutations I can try, let me know.

Out of curiosity, if you push a new (i.e. non-existent) datastream up to the objects that have policies, what happens?

Also, the response code that Fedora (I think it's Fedora) is returning is 404 (not found). I would expect that if it was a permission issue, that should be a 403 (unauthorized). Crazy question, but is it possible there's an error in the filename of the datastream you are pushing which would make it not match an existing object?

[mjordan]

Scrap that last question, I tried it and got a different error:

Do you want to update each object's DC datastream using the new MODS? (y/n): y
MODS datastream pushed to object objtest:181                                                                                                                        [ok]
DC datastream for object objtest:181 regenerated from MODS                                                                                                          [ok]
The specified object (testingx:5) does not exist or is not accessible.                                                                                              [error]

[bondjimbond]

I noticed that the XACML policies do not include user "islandora" in the list of who can view. "islandora" is the Apache user, I believe. Do you think it's possible that this is why it's failing? Except I'm running the drush command as user 1, but perhaps some part of the code is trying to execute as apache?

[mjordan]

Not that I know of, and if it did, wouldn't it fail for me too?

[mjordan]

I'm working on a vagrant box. Can you try to replicate it on one too? If you can, I am not testing the right way.