Re: [dspace-tech] Authentication with Shibboleth

['Tim Donohue' via DSpace Technical Support]

Hi Bill,

Are you referring to DSpace 7 Beta 5?  If so, there is a known issue with 
Shibboleth authentication right nowwe accidentally broke it between Beta 4 
and Beta 5.

Here's the bug ticket: https://github.com/DSpace/dspace-angular/issues/1108
And here's the PR that should​ fix it: 
https://github.com/DSpace/DSpace/pull/3242  (this is currently under review, 
but it's working on my end)

Tim

From: 'Bill Tantzen' via DSpace Technical Support 
Sent: Monday, April 26, 2021 9:06 AM
To: DSpace Technical Support 
Subject: [dspace-tech] Authentication with Shibboleth

All,
So far, I have not been able to authenticate users via Shibboleth.  I have 
found this issue: 
DS-4396.
 Is this where the issue of shib login currently stands?  An further 
information?
Thanks,
~~ Bill

--
Human wheels spin round and round
While the clock keeps the pace... -- John Mellencamp

Bill TantzenUniversity of Minnesota Libraries
612-626-9949 (U of M)612-325-1777 (cell)

--
All messages to this mailing list should adhere to the Code of Conduct: 
https://duraspace.org/about/policies/code-of-conduct/
---
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/CADgrb7Hho5QuU69Lx2s9h00%2BpoUuUsMct5JnamoijJM0UWT8MQ%40mail.gmail.com.

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://duraspace.org/about/policies/code-of-conduct/
--- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/DM5PR2201MB11480193BCA79708070DD56DED429%40DM5PR2201MB1148.namprd22.prod.outlook.com.

Re: [dspace-tech] authentication methods to use for swordv2 different from xmlui

[Mark H. Wood]

On Wed, Apr 15, 2020 at 01:32:13PM -0400, Jose Blanco wrote:
> In config/modules/authentication.cfg  I have indicated the auth method I
> want the system to use from the browser.
> 
> *plugin.sequence.org.dspace.authenticate.AuthenticationMethod =
> org.dspace.authenticate.PasswordAuthentication*
> 
> I want the system to use a different auth method when interacting with
> SWORDv2.  How do I go about doing this in 6.3?

I have not tried this, but I think that the least intrusive way might
be to add a ServletContextConfiguration source to
dspace/config/config-definition.xml:

  
  

You may need to add this in the  section, to ensure that the
source's tag is defined:

  

  

Then you could add a ContextParameter to the 'swordv2' Context:

  

You can probably use 'bin/dspace dsprop --property=dspace.dir' to more
conveniently test config-definition.xml until you get no errors, or at
least until the error you get is that there is no Servlet context.

Please let us know if this works.  I think we ought to make this a
standard feature, if it does.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/20200416133243.GA20795%40IUPUI.Edu.


signature.asc
Description: PGP signature

Re: [dspace-tech] authentication methods to use for swordv2 different from xmlui

[Shaun donovan]

Correct. Good Luck!

Shaun

On 2020/04/15 20:39, Jose Blanco wrote:
I was looking over the code, and this makes sense. Thank you.  I will 
give it a try.  I guess the method you are using in this code is 
PasswordAuthentication? Correct?

Thank you again!
-Jose

On Wed, Apr 15, 2020 at 2:31 PM Shaun donovan > wrote:


Hi Jose.

To accomplish the same thing in 6.3, I had to add two new methods
to

dspace-api/src/main/java/org/dspace/authenticate/AuthenticationServiceImpl.java:

Line 74

@Override
public int authenticateSword(Context context, String un, String
pw, String realm, HttpServletRequest request) {
PasswordAuthentication AuthenticationMethod = new
PasswordAuthentication();

// better is lowest, so start with the highest.
int bestRet = PasswordAuthentication.BAD_ARGS;

// return on first success, otherwise "best" outcome.
int ret = 0;
try {
ret = AuthenticationMethod.authenticate(context, un, pw, realm,
request);
} catch (SQLException e) {
ret = PasswordAuthentication.NO_SUCH_USER;
}
if (ret == PasswordAuthentication.SUCCESS) {
EPerson me = context.getCurrentUser();
me.setLastActive(new Date());
try {
ePersonService.update(context, me);
} catch (SQLException ex) {
log.error("Could not update last-active stamp", ex);
} catch (AuthorizeException ex) {
log.error("Could not update last-active stamp", ex);
}
return ret;
}
if (ret < bestRet) {
bestRet = ret;
}
return bestRet; And line 210: @Override
public List getSpecialGroupsSword(Context context,
HttpServletRequest request) throws SQLException{
PasswordAuthentication method = new PasswordAuthentication();
List result = new ArrayList<>();
int totalLen = 0;
List gl = method.getSpecialGroups(context, request);
if (gl.size() > 0)
{
result.addAll(gl);
totalLen += gl.size();
}
return result;
Then I had to reference them in the interface

dspace-api/src/main/java/org/dspace/authenticate/service/AuthenticationService.java
(line 188):
public int authenticateSword(Context context, String un, String
pw, String realm, HttpServletRequest request);
public List getSpecialGroupsSword(Context context,
HttpServletRequest request) throws SQLException;

And lastly for swordv2 I had to use them in
dspace-swordv2/src/main/java/org/dspace/sword2/SwordAuthenticator.java
line 85-86
|||int auth = authenticationService ||.authenticateSword(context, un, pw, null, null); 
Line 196-197 ||List specialGroups = authenticationService 
||.getSpecialGroupsSword(context, null); Line 228-229 ||List specialGroups = 
authenticationService |   |.getSpecialGroupsSword(oboContext, null); Rebuild and 
redeploy.
If you want it for swordV1 as well, you will need to also make the
last set of changes to
dspace-sword/src/main/java/org/dspace/sword/SWORDAuthenticator.java
as well as the following import: ||import 
org.dspace.authenticate.PasswordAuthentication; Please
note that I did this to allow XMLUI to use my ADFS authentication
while allowing Sword and SwordV2 to use password authentication.
You will need to fix accordingly Hope this helps. Shaun |||

On 2020/04/15 19:32, Jose Blanco wrote:

In config/modules/authentication.cfg  I have indicated the auth
method I want the system to use from the browser.

*plugin.sequence.org.dspace.authenticate.AuthenticationMethod =
org.dspace.authenticate.PasswordAuthentication*

I want the system to use a different auth method when interacting
with SWORDv2.  How do I go about doing this in 6.3?

For 5.1, I duplicated some code to get that to work. But I think
in this environment that would be more difficult, perhaps not
even necessary?


-Jose


-- 
All messages to this mailing list should adhere to the DuraSpace

Code of Conduct:
https://duraspace.org/about/policies/code-of-conduct/
---
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+unsubscr...@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/dspace-tech/CAK%3DKc-siPG1roGc8mAvWTQUCpA%2BVWmMvKypM%3DOuMx%3D%3DGAyA_gw%40mail.gmail.com

.


--
All messages to this mailing list should adhere to the DuraSpace Code 
of Conduct: https://duraspace.org/about/policies/code-of-conduct/

---
You received this message because you are subscribed to the Google 
Groups "DSpace Technical Support" group.
To unsubscribe from this gr

Re: [dspace-tech] authentication methods to use for swordv2 different from xmlui

[Jose Blanco]

I was looking over the code, and this makes sense.  Thank you.  I will give
it a try.  I guess the method you are using in this code is
PasswordAuthentication?
Correct?

Thank you again!
-Jose


On Wed, Apr 15, 2020 at 2:31 PM Shaun donovan  wrote:

> Hi Jose.
>
> To accomplish the same thing in 6.3, I had to add two new methods to
> dspace-api/src/main/java/org/dspace/authenticate/AuthenticationServiceImpl.java:
>
> Line 74
>
>   @Overridepublic int authenticateSword(Context context, String un, 
> String pw, String realm, HttpServletRequest request) {
> PasswordAuthentication AuthenticationMethod = new PasswordAuthentication();   
>   // better is lowest, so start with the highest.int bestRet 
> = PasswordAuthentication.BAD_ARGS;// return on first success, 
> otherwise "best" outcome.int ret = 0;try {ret = 
> AuthenticationMethod.authenticate(context, un, pw, realm, request);} 
> catch (SQLException e) {ret = 
> PasswordAuthentication.NO_SUCH_USER;}if (ret == 
> PasswordAuthentication.SUCCESS) {EPerson me = 
> context.getCurrentUser();me.setLastActive(new Date());
> try {ePersonService.update(context, me);} catch 
> (SQLException ex) {log.error("Could not update last-active 
> stamp", ex);} catch (AuthorizeException ex) {
> log.error("Could not update last-active stamp", ex);}
> return ret;}if (ret < bestRet) {bestRet = ret;
> }return bestRet;
> And line 210:@Overridepublic List 
> getSpecialGroupsSword(Context context, HttpServletRequest request) throws 
> SQLException{  PasswordAuthentication method = new 
> PasswordAuthentication();   List result = new ArrayList<>();   
>   int totalLen = 0;List gl = 
> method.getSpecialGroups(context, request);if (gl.size() > 0){ 
>result.addAll(gl);totalLen += gl.size();}  
>   return result;
> Then I had to reference them in the interface  
> dspace-api/src/main/java/org/dspace/authenticate/service/AuthenticationService.java
>  (line 188):public int authenticateSword(Context context, String un, 
> String pw, String realm, HttpServletRequest request);  public List 
> getSpecialGroupsSword(Context context, HttpServletRequest request) throws 
> SQLException;
> And lastly for swordv2 I had to use them in 
> dspace-swordv2/src/main/java/org/dspace/sword2/SwordAuthenticator.java
>
> line 85-86   int auth = authenticationService  
> .authenticateSword(context, un, pw, null, null);
> Line 196-197   List specialGroups = authenticationService  
> .getSpecialGroupsSword(context, null);
> Line 228-229   List specialGroups = authenticationService  
> .getSpecialGroupsSword(oboContext, null);
> Rebuild and redeploy. If you want it for swordV1 as well, you will need to 
> also make the last set of changes to 
> dspace-sword/src/main/java/org/dspace/sword/SWORDAuthenticator.java as well 
> as the following import:import org.dspace.authenticate.PasswordAuthentication;
> Please note that I did this to allow XMLUI to use my ADFS authentication 
> while allowing Sword and SwordV2 to use password authentication. You will 
> need to fix accordingly
>
> Hope this helps.
>
> Shaun
>
> On 2020/04/15 19:32, Jose Blanco wrote:
>
> In config/modules/authentication.cfg  I have indicated the auth method I
> want the system to use from the browser.
>
> *plugin.sequence.org.dspace.authenticate.AuthenticationMethod =
> org.dspace.authenticate.PasswordAuthentication*
>
> I want the system to use a different auth method when interacting with
> SWORDv2.  How do I go about doing this in 6.3?
>
> For 5.1, I duplicated some code to get that to work.  But I think in this
> environment that would be more difficult, perhaps not even necessary?
>
>
> -Jose
>
>
> --
> All messages to this mailing list should adhere to the DuraSpace Code of
> Conduct: https://duraspace.org/about/policies/code-of-conduct/
> ---
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dspace-tech/CAK%3DKc-siPG1roGc8mAvWTQUCpA%2BVWmMvKypM%3DOuMx%3D%3DGAyA_gw%40mail.gmail.com
> 
> .
>
>

-- 
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To u

Re: [dspace-tech] authentication methods to use for swordv2 different from xmlui

[Shaun donovan]

Hi Jose.

To accomplish the same thing in 6.3, I had to add two new methods to 
dspace-api/src/main/java/org/dspace/authenticate/AuthenticationServiceImpl.java:


Line 74

@Override
public int authenticateSword(Context context, String un, String pw, 
String realm, HttpServletRequest request) {

PasswordAuthentication AuthenticationMethod = new PasswordAuthentication();

// better is lowest, so start with the highest.
int bestRet = PasswordAuthentication.BAD_ARGS;

// return on first success, otherwise "best" outcome.
int ret = 0;
try {
ret = AuthenticationMethod.authenticate(context, un, pw, realm, request);
} catch (SQLException e) {
ret = PasswordAuthentication.NO_SUCH_USER;
}
if (ret == PasswordAuthentication.SUCCESS) {
EPerson me = context.getCurrentUser();
me.setLastActive(new Date());
try {
ePersonService.update(context, me);
} catch (SQLException ex) {
log.error("Could not update last-active stamp", ex);
} catch (AuthorizeException ex) {
log.error("Could not update last-active stamp", ex);
}
return ret;
}
if (ret < bestRet) {
bestRet = ret;
}
return bestRet; And line 210: @Override
public List getSpecialGroupsSword(Context context, 
HttpServletRequest request) throws SQLException{

PasswordAuthentication method = new PasswordAuthentication();
List result = new ArrayList<>();
int totalLen = 0;
List gl = method.getSpecialGroups(context, request);
if (gl.size() > 0)
{
result.addAll(gl);
totalLen += gl.size();
}
return result;
Then I had to reference them in the interface 
dspace-api/src/main/java/org/dspace/authenticate/service/AuthenticationService.java 
(line 188):
public int authenticateSword(Context context, String un, String pw, 
String realm, HttpServletRequest request);
public List getSpecialGroupsSword(Context context, 
HttpServletRequest request) throws SQLException;


And lastly for swordv2 I had to use them in 
dspace-swordv2/src/main/java/org/dspace/sword2/SwordAuthenticator.java 
line 85-86
|||int auth = authenticationService ||.authenticateSword(context, un, pw, null, null); Line 196-197 ||List specialGroups = authenticationService ||.getSpecialGroupsSword(context, null); Line 228-229 ||List specialGroups = authenticationService |   |.getSpecialGroupsSword(oboContext, null); Rebuild and redeploy. If you 
want it for swordV1 as well, you will need to also make the last set of 
changes to 
dspace-sword/src/main/java/org/dspace/sword/SWORDAuthenticator.java as 
well as the following import: ||import org.dspace.authenticate.PasswordAuthentication; Please note that 
I did this to allow XMLUI to use my ADFS authentication while allowing 
Sword and SwordV2 to use password authentication. You will need to fix 
accordingly Hope this helps. Shaun |||


On 2020/04/15 19:32, Jose Blanco wrote:
In config/modules/authentication.cfg  I have indicated the auth method 
I want the system to use from the browser.


*plugin.sequence.org.dspace.authenticate.AuthenticationMethod = 
org.dspace.authenticate.PasswordAuthentication*


I want the system to use a different auth method when interacting with 
SWORDv2.  How do I go about doing this in 6.3?


For 5.1, I duplicated some code to get that to work.  But I think in 
this environment that would be more difficult, perhaps not even necessary?



-Jose


--
All messages to this mailing list should adhere to the DuraSpace Code 
of Conduct: https://duraspace.org/about/policies/code-of-conduct/

---
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+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/CAK%3DKc-siPG1roGc8mAvWTQUCpA%2BVWmMvKypM%3DOuMx%3D%3DGAyA_gw%40mail.gmail.com 
.


--
All messages to this mailing list should adhere to the DuraSpace Code of 
Conduct: https://duraspace.org/about/policies/code-of-conduct/
--- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/3ac5d878-5c31-e81e-fe33-50aa7c9e9a1e%40teqcle.co.za.

Re: [dspace-tech] Authentication error when depositing via 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


From: Tim Donohue 
Sent: 23 April 2018 16:59:43
To: MALMQUIST Hrafn
Cc: dspace-tech@googlegroups.com
Subject: Re: [dspace-tech] Authentication error when depositing via SWORDv2

Hello Hrafn,

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.

And again, SWORDv2 seems to work perfectly fine via "curl".  My best guess is 
that the Python library you are using is somehow sending an unexpected request 
to DSpace. Unfortunately, I don't know Python, so I'm not sure what exactly 
could be the problem in that library.

Tim

On Mon, Apr 23, 2018 at 10:32 AM MALMQUIST Hrafn 
mailto:hrafn.malmqu...@ed.ac.uk>> wrote:

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


From: dspace-tech@googlegroups.com<mailto:dspace-tech@googlegroups.com> 
mailto:dspace-tech@googlegroups.com>> on behalf 
of MALMQUIST Hrafn mailto:hrafn.malmqu...@ed.ac.uk>>
Sent: 17 April 2018 14:03:30

To: tdono...@duraspace.org<mailto:tdono...@duraspace.org>
Cc: dspace-tech@googlegroups.com<mailto:dspace-tech@googlegroups.com>
Subject: Re: [dspace-tech] Authentication error when depositing via SWORDv2

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





From: dspace-tech@googlegroups.com<mailto:dspace-tech@googlegroups.com> 
mailto:dspace-tech@googlegroups.com>> on behalf 
of Tim Donohue mailto:tdono...@duraspace.org>>
Sent: 13 April 2018 16:18:08
To: MALMQUIST Hrafn
Cc: dspace-tech@googlegroups.com<mailto:dspace-tech@googlegroups.com>
Subject: Re: [dspace-tech] Authentication error when depositing via SWORDv2

Hello Hrafn,

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*

So, for example, I can easily reproduce it via "curl", if I simply do a GET 
against an existing item in the demo site.  (For this example, I'm using this 
existing item: http://demo.dspace.org/xmlui/handle/10673/5 which has an 
internal ID of "1fd633f5-5df9-4b50-b23f-bb1f951e57a4")

For example, this simple GET request will throw that "No plugin can disseminate 
the requested formats" error:

curl -i -u dspacedemo+ad...@gmail.com:[password] -X GET 
http://demo.dspace.org/swordv2/edit-media/1fd633f5-5df9-4b50-b23f-bb1f951e57a4

However, if I do the same GET request, but tell it I want "atom+xml" format, 
then the request *succeeds* and I get back an ATOM response with metadata about 
that Item

curl -i -H "Accept:application/atom+xml" -u 
dspacedemo+ad...@gmail.com:[password] -X GET 
http://demo.dspace.org/swordv2/edit-media/1fd633f5-5df9-4b50-b23f-bb1f951e57a4

So, that error doesn't seem to be a bug, but instead is an improper call to the 
"edit-media" path, as that path expects that you will pass along an "Accept" 
header in your request. Based on the DSpace SWORDv2 disseminator configuration, 
there are a limited number of valid "Accept" headers that DSpace supports by 
default -- they are configured here: 
https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/modules/swordv2-server.cfg#L254

My suspicion

Re: [dspace-tech] Authentication error when depositing via SWORDv2

[Tim Donohue]

Hello Hrafn,

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.

And again, SWORDv2 seems to work perfectly fine via "curl".  My best guess
is that the Python library you are using is somehow sending an unexpected
request to DSpace. Unfortunately, I don't know Python, so I'm not sure what
exactly could be the problem in that library.

Tim

On Mon, Apr 23, 2018 at 10:32 AM MALMQUIST Hrafn 
wrote:

> 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
> --
> *From:* dspace-tech@googlegroups.com  on
> behalf of MALMQUIST Hrafn 
> *Sent:* 17 April 2018 14:03:30
>
> *To:* tdono...@duraspace.org
> *Cc:* dspace-tech@googlegroups.com
> *Subject:* Re: [dspace-tech] Authentication error when depositing via
> SWORDv2
>
> 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
>
>
>
> ----------
> *From:* dspace-tech@googlegroups.com  on
> behalf of Tim Donohue 
> *Sent:* 13 April 2018 16:18:08
> *To:* MALMQUIST Hrafn
> *Cc:* dspace-tech@googlegroups.com
> *Subject:* Re: [dspace-tech] Authentication error when depositing via
> SWORDv2
>
> Hello Hrafn,
>
> 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*
>
> So, for example, I can easily reproduce it via "curl", if I simply do a
> GET against an existing item in the demo site.  (For this example, I'm
> using this existing item: http://demo.dspace.org/xmlui/handle/10673/5 which
> has an internal ID of "1fd633f5-5df9-4b50-b23f-bb1f951e57a4")
>
> For example, this simple GET request will throw that "No plugin can
> disseminate the requested formats" error:
>
> curl -i -u dspacedemo+ad...@gmail.com:[password] -X GET
> http://demo.dspace.org/swordv2/edit-media/1fd633f5-5df9-4b50-b23f-bb1f951e57a4
>
> However, if I do the same GET request, but tell it I want "atom+xml"
> format, then the request *succeeds* and I get back an ATOM response with
> metadata about that Item
>
> curl -i -H "Accept:application/atom+xml" -u 
> dspacedemo+ad...@gmail.com:[password]
> -X GET
> http://demo.dspace.org/swordv2/edit-media/1fd633f5-5df9-4b50-b23f-bb1f951e57a4
>
> So, that error doesn't seem to be a bug, but instead is an improper call
> to the "edit-media" path, as that path expects that you will pass along an
> "Accept" header in your request. Based on the DSpace SWORDv2 disseminator
> configuration, there are a limited number of valid "Accept" headers that
> DSpace supports by default -- they are configured here:
> https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/modules/swordv2-server.cfg#L254
>
>
> My suspicion here is that some of your testing is passing this "Accept"
> header along properly...while other scripts/tests may not be.  Either that,
> or this "No plugin can disseminate the requested formats" error is not the
> core problem you are encountering.  In which case, we may need more
> examples of reproducing the core proble

Re: [dspace-tech] Authentication error when depositing via SWORDv2

[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


From: dspace-tech@googlegroups.com  on behalf of 
MALMQUIST Hrafn 
Sent: 17 April 2018 14:03:30
To: tdono...@duraspace.org
Cc: dspace-tech@googlegroups.com
Subject: Re: [dspace-tech] Authentication error when depositing via SWORDv2


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





From: dspace-tech@googlegroups.com  on behalf of 
Tim Donohue 
Sent: 13 April 2018 16:18:08
To: MALMQUIST Hrafn
Cc: dspace-tech@googlegroups.com
Subject: Re: [dspace-tech] Authentication error when depositing via SWORDv2

Hello Hrafn,

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*

So, for example, I can easily reproduce it via "curl", if I simply do a GET 
against an existing item in the demo site.  (For this example, I'm using this 
existing item: http://demo.dspace.org/xmlui/handle/10673/5 which has an 
internal ID of "1fd633f5-5df9-4b50-b23f-bb1f951e57a4")

For example, this simple GET request will throw that "No plugin can disseminate 
the requested formats" error:

curl -i -u dspacedemo+ad...@gmail.com:[password] -X GET 
http://demo.dspace.org/swordv2/edit-media/1fd633f5-5df9-4b50-b23f-bb1f951e57a4

However, if I do the same GET request, but tell it I want "atom+xml" format, 
then the request *succeeds* and I get back an ATOM response with metadata about 
that Item

curl -i -H "Accept:application/atom+xml" -u 
dspacedemo+ad...@gmail.com:[password] -X GET 
http://demo.dspace.org/swordv2/edit-media/1fd633f5-5df9-4b50-b23f-bb1f951e57a4

So, that error doesn't seem to be a bug, but instead is an improper call to the 
"edit-media" path, as that path expects that you will pass along an "Accept" 
header in your request. Based on the DSpace SWORDv2 disseminator configuration, 
there are a limited number of valid "Accept" headers that DSpace supports by 
default -- they are configured here: 
https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/modules/swordv2-server.cfg#L254

My suspicion here is that some of your testing is passing this "Accept" header 
along properly...while other scripts/tests may not be.  Either that, or this 
"No plugin can disseminate the requested formats" error is not the core problem 
you are encountering.  In which case, we may need more examples of reproducing 
the core problem (ideally via "curl" commands, as with "curl" it is much easier 
to see the headers/etc that are being passed via the request).

Good luck,

- Tim



On Wed, Apr 11, 2018 at 8:27 AM MALMQUIST Hrafn 
mailto:hrafn.malmqu...@ed.ac.uk>> wrote:

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: dspacedemo+ad...@gmail.com<mailto:dspacedemo%2bad...@gmail.com>

pass: dspace


Any thoughts?


Hrafn


From: dspace-tech@googlegroups.co

Re: [dspace-tech] Authentication error when depositing via SWORDv2

[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





From: dspace-tech@googlegroups.com  on behalf of 
Tim Donohue 
Sent: 13 April 2018 16:18:08
To: MALMQUIST Hrafn
Cc: dspace-tech@googlegroups.com
Subject: Re: [dspace-tech] Authentication error when depositing via SWORDv2

Hello Hrafn,

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*

So, for example, I can easily reproduce it via "curl", if I simply do a GET 
against an existing item in the demo site.  (For this example, I'm using this 
existing item: http://demo.dspace.org/xmlui/handle/10673/5 which has an 
internal ID of "1fd633f5-5df9-4b50-b23f-bb1f951e57a4")

For example, this simple GET request will throw that "No plugin can disseminate 
the requested formats" error:

curl -i -u dspacedemo+ad...@gmail.com:[password] -X GET 
http://demo.dspace.org/swordv2/edit-media/1fd633f5-5df9-4b50-b23f-bb1f951e57a4

However, if I do the same GET request, but tell it I want "atom+xml" format, 
then the request *succeeds* and I get back an ATOM response with metadata about 
that Item

curl -i -H "Accept:application/atom+xml" -u 
dspacedemo+ad...@gmail.com:[password] -X GET 
http://demo.dspace.org/swordv2/edit-media/1fd633f5-5df9-4b50-b23f-bb1f951e57a4

So, that error doesn't seem to be a bug, but instead is an improper call to the 
"edit-media" path, as that path expects that you will pass along an "Accept" 
header in your request. Based on the DSpace SWORDv2 disseminator configuration, 
there are a limited number of valid "Accept" headers that DSpace supports by 
default -- they are configured here: 
https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/modules/swordv2-server.cfg#L254

My suspicion here is that some of your testing is passing this "Accept" header 
along properly...while other scripts/tests may not be.  Either that, or this 
"No plugin can disseminate the requested formats" error is not the core problem 
you are encountering.  In which case, we may need more examples of reproducing 
the core problem (ideally via "curl" commands, as with "curl" it is much easier 
to see the headers/etc that are being passed via the request).

Good luck,

- Tim



On Wed, Apr 11, 2018 at 8:27 AM MALMQUIST Hrafn 
mailto:hrafn.malmqu...@ed.ac.uk>> wrote:

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: dspacedemo+ad...@gmail.com<mailto:dspacedemo%2bad...@gmail.com>

pass: dspace


Any thoughts?


Hrafn


From: dspace-tech@googlegroups.com<mailto:dspace-tech@googlegroups.com> 
mailto:dspace-tech@googlegroups.com>> on behalf 
of MALMQUIST Hrafn mailto:hrafn.malmqu...@ed.ac.uk>>
Sent: 11 April 2018 10:32:05
To: tdono...@duraspace.org<mailto:tdono...@duraspace.org>

Cc: dspace-tech@googlegroups.com<mailto:dspace-tech@googlegroups.com>
Subject: Re: [dspace-tech] Authentication error when depositing via SWORDv2

Hello Tim


Thank you for taking the time to repl

Re: [dspace-tech] Authentication error when depositing via SWORDv2

[Tim Donohue]

Hello Hrafn,

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*

So, for example, I can easily reproduce it via "curl", if I simply do a GET
against an existing item in the demo site.  (For this example, I'm using
this existing item: http://demo.dspace.org/xmlui/handle/10673/5 which has
an internal ID of "1fd633f5-5df9-4b50-b23f-bb1f951e57a4")

For example, this simple GET request will throw that "No plugin can
disseminate the requested formats" error:

curl -i -u dspacedemo+ad...@gmail.com:[password] -X GET
http://demo.dspace.org/swordv2/edit-media/1fd633f5-5df9-4b50-b23f-bb1f951e57a4

However, if I do the same GET request, but tell it I want "atom+xml"
format, then the request *succeeds* and I get back an ATOM response with
metadata about that Item

curl -i -H "Accept:application/atom+xml" -u
dspacedemo+ad...@gmail.com:[password]
-X GET
http://demo.dspace.org/swordv2/edit-media/1fd633f5-5df9-4b50-b23f-bb1f951e57a4

So, that error doesn't seem to be a bug, but instead is an improper call to
the "edit-media" path, as that path expects that you will pass along an
"Accept" header in your request. Based on the DSpace SWORDv2 disseminator
configuration, there are a limited number of valid "Accept" headers that
DSpace supports by default -- they are configured here:
https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace/config/modules/swordv2-server.cfg#L254


My suspicion here is that some of your testing is passing this "Accept"
header along properly...while other scripts/tests may not be.  Either that,
or this "No plugin can disseminate the requested formats" error is not the
core problem you are encountering.  In which case, we may need more
examples of reproducing the core problem (ideally via "curl" commands, as
with "curl" it is much easier to see the headers/etc that are being passed
via the request).

Good luck,

- Tim



On Wed, Apr 11, 2018 at 8:27 AM MALMQUIST Hrafn 
wrote:

> 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: dspacedemo+ad...@gmail.com
>
> pass: dspace
>
>
> Any thoughts?
>
>
> Hrafn
> --
> *From:* dspace-tech@googlegroups.com  on
> behalf of MALMQUIST Hrafn 
> *Sent:* 11 April 2018 10:32:05
> *To:* tdono...@duraspace.org
>
> *Cc:* dspace-tech@googlegroups.com
> *Subject:* Re: [dspace-tech] Authentication error when depositing via
> SWORDv2
>
> 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:Starting new HTTP connection (1):
> test.digitalpreservation.is.ed.ac.uk
> DEBUG:urllib3.connectionpool:
> http://test.digitalpreservation.is.ed.ac.uk:80 "POST
> /swordv2/edit-media/a454b207-dea5-4f

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: dspacedemo+ad...@gmail.com

pass: dspace


Any thoughts?


Hrafn


From: dspace-tech@googlegroups.com  on behalf of 
MALMQUIST Hrafn 
Sent: 11 April 2018 10:32:05
To: tdono...@duraspace.org
Cc: dspace-tech@googlegroups.com
Subject: Re: [dspace-tech] Authentication error when depositing via SWORDv2


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:Starting new HTTP connection (1): 
test.digitalpreservation.is.ed.ac.uk
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.malmqu...@ed.ac.uk:session_id=0:replace_failed_authorisation:user=hrafn.malmqu...@ed.ac.uk,on_behalf_of=none


Now, the fact that the curl command works and also a simple equivalent 
submission using the python requests library (see attached request.py) tells me 
that the SWORD server is functioning correctly and that this can't be a proper 
permissions issue.

Best regards, Hrafn



From: Tim Donohue 
Sent: 10 April 2018 15:10:31
To: MALMQUIST Hrafn
Cc: dspace-tech@googlegroups.com
Subject: Re: [dspace-tech] Authentication error when depositing via SWORDv2

Hello Hrafn,

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.

So, my guess is that the real error behind the 403 response likely is in the 
DSpace server logs (or maybe the Tomcat logs).  If you need more information on 
finding the error in the logs, take a look at 
https://wiki.duraspace.org/display/DSPACE/Troubleshoot+an+error

I'd recommend sending the error stack to this mailing list once you find it.  
Hopefully it provides more information so that someone on this list can help.

One final note, I'd recommend double checking that your "curl" command and 
Python script are sending the same comment.  I'm not a Python coder myself, but 
it looks to me like you've commented out the "Packaging: 
http://purl.org/net/sword/package/Binary"; header in your Python script...while 
it is included in your "curl" script.


Tim



On Mon, Apr 9, 2018 at 10:27 AM MALMQUIST Hrafn 
mailto:hrafn.malmqu...@ed.ac.uk>> wrote:

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 t

Re: [dspace-tech] Authentication error when depositing via SWORDv2

[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:Starting new HTTP connection (1): 
test.digitalpreservation.is.ed.ac.uk
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.malmqu...@ed.ac.uk:session_id=0:replace_failed_authorisation:user=hrafn.malmqu...@ed.ac.uk,on_behalf_of=none


Now, the fact that the curl command works and also a simple equivalent 
submission using the python requests library (see attached request.py) tells me 
that the SWORD server is functioning correctly and that this can't be a proper 
permissions issue.

Best regards, Hrafn



From: Tim Donohue 
Sent: 10 April 2018 15:10:31
To: MALMQUIST Hrafn
Cc: dspace-tech@googlegroups.com
Subject: Re: [dspace-tech] Authentication error when depositing via SWORDv2

Hello Hrafn,

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.

So, my guess is that the real error behind the 403 response likely is in the 
DSpace server logs (or maybe the Tomcat logs).  If you need more information on 
finding the error in the logs, take a look at 
https://wiki.duraspace.org/display/DSPACE/Troubleshoot+an+error

I'd recommend sending the error stack to this mailing list once you find it.  
Hopefully it provides more information so that someone on this list can help.

One final note, I'd recommend double checking that your "curl" command and 
Python script are sending the same comment.  I'm not a Python coder myself, but 
it looks to me like you've commented out the "Packaging: 
http://purl.org/net/sword/package/Binary"; header in your Python script...while 
it is included in your "curl" script.


Tim



On Mon, Apr 9, 2018 at 10:27 AM MALMQUIST Hrafn 
mailto:hrafn.malmqu...@ed.ac.uk>> wrote:

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:


curl -i --data-binary "@strategic_plan_2016.pdf" -H 
"Content-Disposition:attachment; filename=strategic_plan_2016.pdf" -H 
"Content-Type:application/pdf" -H 
"Packaging:http://purl.org/net/sword/package/Binary"; -u 
hrafn.malmqu...@ed.ac.uk:** -X POST 
http://test.digitalpreservation.is.ed.ac.uk/swordv2/collection/123456789/2

the python script that generates the error is copy pasted below

There is one caveat that the SSL certificate on the server is broken which 
might be an issue (https://github.com/swordapp/python-client-sword2/issues/9).

However I get a 403 response when trying to deposit the files via the Python 
sword client. The edit-media file 
(http://test.digitalpreservation.is.ed.ac.uk/swordv2/edit-media/e9598d4d-ba1c-4710-95b9-000b8ce30772)
 gives this error:

http://purl.org/net/sword/terms/"; 
href="http://purl.org/net/sword/error/ErrorCon

Re: [dspace-tech] Authentication error when depositing via SWORDv2

[Tim Donohue]

Hello Hrafn,

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.

So, my guess is that the real error behind the 403 response likely is in
the DSpace server logs (or maybe the Tomcat logs).  If you need more
information on finding the error in the logs, take a look at
https://wiki.duraspace.org/display/DSPACE/Troubleshoot+an+error

I'd recommend sending the error stack to this mailing list once you find
it.  Hopefully it provides more information so that someone on this list
can help.

One final note, I'd recommend double checking that your "curl" command and
Python script are sending the same comment.  I'm not a Python coder myself,
but it looks to me like you've commented out the "Packaging:
http://purl.org/net/sword/package/Binary"; header in your Python
script...while it is included in your "curl" script.


Tim



On Mon, Apr 9, 2018 at 10:27 AM MALMQUIST Hrafn 
wrote:

> 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:
>
>
> curl -i --data-binary "@strategic_plan_2016.pdf" -H
> "Content-Disposition:attachment; filename=strategic_plan_2016.pdf" -H
> "Content-Type:application/pdf" -H "Packaging:
> http://purl.org/net/sword/package/Binary"; -u 
> hrafn.malmqu...@ed.ac.uk:** -X
> POST
> http://test.digitalpreservation.is.ed.ac.uk/swordv2/collection/123456789/2
>
> the python script that generates the error is copy pasted below
>
> There is one caveat that the SSL certificate on the server is broken which
> might be an issue (
> https://github.com/swordapp/python-client-sword2/issues/9).
>
> However I get a 403 response when trying to deposit the files via
> the Python sword client. The edit-media file (
> http://test.digitalpreservation.is.ed.ac.uk/swordv2/edit-media/e9598d4d-ba1c-4710-95b9-000b8ce30772)
>  gives
> this error:
>
> http://purl.org/net/sword/terms/"; href="
> http://purl.org/net/sword/error/ErrorContent";>
> http://www.w3.org/2005/Atom";>ERROR
> http://www.w3.org/2005/Atom";>
> 2018-04-09T10:39:20Z
> http://www.w3.org/2005/Atom"; uri="
> http://www.dspace.org/ns/sword/2.0/"; version="2.0">dspace-h...@myu.edu
> 
> Processing failed
> http://www.w3.org/2005/Atom";>No plugin can
> disseminate the requested formats
> 
> org.swordapp.server.SwordError: No plugin can disseminate the requested
> formats at
> org.dspace.sword2.SwordDisseminatorFactory.getContentInstance(SwordDisseminatorFactory.java:112)
> at
> org.dspace.sword2.MediaResourceManagerDSpace.getItemResource(MediaResourceManagerDSpace.java:114)
> at
> org.dspace.sword2.MediaResourceManagerDSpace.getMediaResourceRepresentation(MediaResourceManagerDSpace.java:229)
> at org.swordapp.server.MediaResourceAPI.get(MediaResourceAPI.java:82) at
> org.swordapp.server.MediaResourceAPI.get(MediaResourceAPI.java:33) at
> org.swordapp.server.servlets.MediaResourceServletDefault.doGet(MediaResourceServletDefault.java:35)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:622) at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> at
> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
> at org.apache.coyote.ajp.AjpProcesso

Re: [dspace-tech] Authentication

[Keith Jones]

Thanks Andrea,

This method works. I appreciate the help.

Keith

On Fri, Sep 16, 2016 at 5:51 AM, Andrea Bollini 
wrote:

> Hi Keith,
>
> I do that in the past, if I remember correctly you just need a small
> customization to the org.dspace.authenticate.PasswordAuthentication
>
> change the loginPageURL and the loginPageTitle methods to return null, in
> such way it will be not shown to the user as an authentication option but
> will be available as provider to authenticate the credential collected with
> basic auth for rest/sword.
>
> To keep things more clean you should rename the class and put it in the
> additions module. Remember to change the authentication.cfg file accordly.
>
> Hope this help,
>
> Andrea
>
>
>
>
> Il 08/09/2016 21:47, Keith Jones ha scritto:
>
>
>
> Hi All,
>
> We have an installation of DSpace and we are using CAS as the
> authentication process.
> I'm planning on running SWORD and REST and wanted to know if it is
> possible to by pass the CAS authentication and used the default password
> option, while still having CAS managing authentication when end users log
> into the web interface.
>
> Thanks
> Keith
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to dspace-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> Andrea Bollini
> Chief Technology and Innovation Officer
>
> 4Science,  www.4science.it
> office: Via Edoardo D'Onofrio 304, 00155 Roma, Italy
> mobile: +39 333 934 1808
> skype: a.bollini
> linkedin: andreabollini
> orcid: -0002-9029-1854
>
> an Itway Group Company
> Italy, France, Spain, Portugal, Greece, Turkey, Lebanon, Qatar, U.A.Emirates
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] Authentication

[Andrea Bollini]

Hi Keith,

I do that in the past, if I remember correctly you just need a small 
customization to the org.dspace.authenticate.PasswordAuthentication

change the loginPageURL and the loginPageTitle methods to return null, in such 
way it will be not shown to the user as an authentication option but will be 
available as provider to authenticate the credential collected with basic auth 
for rest/sword.

To keep things more clean you should rename the class and put it in the 
additions module. Remember to change the authentication.cfg file accordly.

Hope this help,

Andrea



Il 08/09/2016 21:47, Keith Jones ha scritto:


Hi All,

We have an installation of DSpace and we are using CAS as the authentication 
process.
I'm planning on running SWORD and REST and wanted to know if it is possible to 
by pass the CAS authentication and used the default password option, while 
still having CAS managing authentication when end users log into the web 
interface.

Thanks
Keith
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to 
dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


--
Andrea Bollini
Chief Technology and Innovation Officer

4Science,  www.4science.it
office: Via Edoardo D'Onofrio 304, 00155 Roma, Italy
mobile: +39 333 934 1808
skype: a.bollini
linkedin: andreabollini
orcid: -0002-9029-1854

an Itway Group Company
Italy, France, Spain, Portugal, Greece, Turkey, Lebanon, Qatar, U.A.Emirates

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.