Authentication error when depositing via SWORDv2
MALMQUIST Hrafn
Hello all
I am getting an error response from DSpace when trying to deposit content via it's SWORDv2 API.
I am using the Python SWORD client library (https://github.com/swordapp/python-client-sword2).
What I find particularly confusing is the fact that when I try to deposit using curl, everything goes smoothly:
import requests
import os
import urllib
col_iri=destination_path,
in_progress=True,
metadata_entry=entry,
)
headers = {
'Content-Type': 'application/pdf', #str(mimetypes.guess_type("strategic_plan_2016.pdf")),
# 'Content-MD5': str(md5sum),
#'Packaging': 'http://purl.org/net/sword/package/Binary',
'Content-Length': str(os.path.getsize("strategic_plan_2016.pdf")),
'Content-Disposition': "attachment; filename=%s" % urllib.quote(os.path.basename("strategic_plan_2016.pdf")),
}
'<entry xmlns="http://www.w3.org/2005/Atom" xmlns:dcterms="http://purl.org/dc/terms/">' \
' <generator uri="http://bitbucket.org/beno/python-sword2" version="0.1"/>' \
' <dcterms:rights.copyright xmlns:atom="http://www.w3.org/2005/Atom">This content may be under copyright. Researchers are responsible for determining the appropriate use or reuse of materials.</dcterms:rights.copyright>' \
' <dcterms:title xmlns:atom="http://www.w3.org/2005/Atom">Strategic Plan DB</dcterms:title>' \
' <atom:title xmlns:atom="http://www.w3.org/2005/Atom">Strategic Plan Atom</atom:title>' \
' <dcterms:date.issued xmlns:atom="http://www.w3.org/2005/Atom">2018</dcterms:date.issued>' \
' <atom:updated xmlns:atom="http://www.w3.org/2005/Atom">2018-04-06T04:08:41.425884</atom:updated>' \
' <dcterms:relation.ispartofseries xmlns:atom="http://www.w3.org/2005/Atom">Central Records Registry - ESTATES</dcterms:relation.ispartofseries>' \
' <dcterms:description.abstract xmlns:atom="http://www.w3.org/2005/Atom"/>' \
' <dcterms:contributor.author xmlns:atom="http://www.w3.org/2005/Atom">University of Edinburgh (Scottish University)</dcterms:contributor.author>' \
'</entry>'
content = data.read()
Tim Donohue
You may want to check the log files on the DSpace server ([dspace]/log/dspace.log.[date]) to see if further information is given on the 403 response you are seeing.
The error you are getting from the "edit-media" file may be *unrelated* to the initial 403 response, as that error seems to be resulting from an inability of DSpace to re-disseminate the deposited file. It specifically states: "No plugin can disseminate the requested formats" That error only occurs if DSpace has trouble disseminating an object -- and has nothing to do with the deposit process.
--
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To post to this group, send email to dspac...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To post to this group, send email to dspac...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org
MALMQUIST Hrafn
Hello Tim
Thank you for taking the time to reply and for good suggestions.
The Edit-media error occurs before I hand over any data about whether or not I intend to deposit files (see attached simple-test.py). In this script I just hand over XML formatted metadata (entry variable) because this gives me the Edit-media IRI which is needed for me to deposit the files (in simple-test.py I am in fact reproducing the process on lines 252-268 on https://github.com/artefactual/archivematica-storage-service/blob/stable/0.11.x/storage_service/locations/models/dspace.py with a view to make line 297 work).
DSpace 6.2 log, at this point shows no error (see attached dspace.log)
Python SWORDv2 Client log for the same process doesn't show an error either (see attached sword-client.log)
So running the simple-test.py will result in an item being created in submissions DSpace with the declared metadata. It seems no error is logged.
If the generated Edit-media IRI is opened, the "No plugin can disseminate the requested formats" error is displayed (which does not show up in logs). If I attempt to deposit files using this Edit-media IRI
I get 403 errors which do show up in the SWORD client log as:
DEBUG:urllib3.connectionpool:http://test.digitalpreservation.is.ed.ac.uk:80 "POST /swordv2/edit-media/a454b207-dea5-4fcb-ba80-1618317d10f0 HTTP/1.1" 403 996
and in the DSpace log as:
2018-04-10 15:07:06,202 INFO org.dspace.sword2.MediaResourceManagerDSpace @ hrafn.m...@ed.ac.uk:session_id=0:replace_failed_authorisation:user=hrafn.m...@ed.ac.uk,on_behalf_of=none
Sent: 10 April 2018 15:10:31
To: MALMQUIST Hrafn
Cc: dspac...@googlegroups.com
Subject: Re: [dspace-tech] Authentication error when depositing via SWORDv2
MALMQUIST Hrafn
Hello
I'm just following up by adding that I replicate can the error on http://demo.dspace.org.
Sending in a metadata only entry is mostly fine (see working.py). For the first few runs they went straight through but then an error was generated in the sword client but the deposited item materialised nonetheless (for instance: http://demo.dspace.org/xmlui/handle/10673/80)
Example of an Edit-IRI http://demo.dspace.org/swordv2/edit/334112ee-077b-4192-9ba3-8606e399aa4d
and the Edit-Media-IRI gives the same error:
http://demo.dspace.org/swordv2/edit-media/334112ee-077b-4192-9ba3-8606e399aa4d
To authenticate
user: dspacede...@gmail.com
pass: dspace
Any thoughts?
Hrafn
Sent: 11 April 2018 10:32:05
To: tdon...@duraspace.org
Tim Donohue
I've had a bit of time to dig on this today. That "No plugin can disseminate the requested formats" error seems to be the result of calling a SWORDv2 path *without passing along an expected header*
MALMQUIST Hrafn
Hello Tim
Thanks again for taking the time to look at this.
Yes, you are correct of course that the attempting to GET the Edit-Media URI without a proper Accept header will throw this "No plugin can disseminate the requested formats" error. I should have realised beforehand that the Edit-Media URI isn't intended for human consumption, I am new to SWORDv2 and I was trying to trace the 403 error so it threw me off .
I've identified a more likely source of my troubles. I'm using the SWORDv2 Python Client library (https://github.com/swordapp/python-client-sword2) and my 31 line Python script (attached dspace-demo.py) that creates a metadata item in Dspace and then attempts to upload a single binary file gets the same 403 error (this is roughly following https://github.com/swordapp/python-client-sword2/wiki/BasicUsage).
In any case, I'm assuming the problem is with the Python Client library and I'm not too keen on trying to trace it further because my alternative solution is to just post the binary using the requests Python library and subsequently updating metadata/permissions using the DSpace REST API.
Best regards, Hrafn
Sent: 13 April 2018 16:18:08
MALMQUIST Hrafn
It just occurred to me that between DSpace versions 5 and 6 the authentication method for the REST API changed.
Any possibility that the authentication for SWORDv2 changed as well?
Hrafn
Tim Donohue
No, the REST API and SWORDv2 interfaces are entirely separate modules/codebases. So, while the authentication method for REST API changed between 5.x and 6.x (to essentially better align it with other DSpace modules), there were no changes to authentication in SWORDv2.
MALMQUIST Hrafn
Hi Tim
Yeah, I realise this seems to be a client library issue. I've more or less decided to got with the REST API instead of SWORDv2.
Hrafn
Sent: 23 April 2018 16:59:43