EPrints Technical Mailing List Archive

Message: #07637

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] Error whilst depositing via SWORD

Hi all,

The patch is now available on GitHub:

https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feprints%2Feprints%2Fcommit%2Fee0c653d450d6e90562d881daaf72&amp;data=01%7C01%7C%7C35d31d531bb54032d82e08d6755aa94f%7C4a5378f929f44d3ebe89669d03ada9d8%7C1&amp;sdata=jHfiWYUUbH%2BjfELTd%2BHsid%2FsTuAl0unNxzLnLPc8bCE%3D&amp;reserved=0
6542fc768a2

I copied and pasted the changes from the 3.4 instance I was working on
and have confirm that the file is syntactically correct.  However, I do
not currently have a working test repository using the 3.3 GitHub
codebase, so I have only checked the functionality works as expected in
my 3.4 version.  Therefore, I would advise testing in your own
environment to be 100% sure this fix works as expected.

Regards

David Newman

On Tue, 2019-01-08 at 10:51 +0000, Newman D.R. via Eprints-tech wrote:
> Hi John,
>
> That would not be too difficult to implement but would require a
> further core change.  I think I will just leave put the patch to fix
> the issue for now and this can be improved if people find it
> necessary
> to do so.
>
> Regards
>
> David Newman
>
> On Tue, 2019-01-08 at 10:04 +0000, John Salter wrote:
> >
> > Hi David,
> > Excellent!
> > I had a bit of a look at this last night - and was trying to get my
> > head round what was newer code, what was older code, and whether
> > anything needed to be elevated into the handler / new methods. It
> > looks like what you've got is all good!
> >
> > One thought about the mediation (with a bit of a GDPR / allow the
> > minimum access needed to do what needs to be done hat on), would it
> > make sense to allow a finer-grained mediate rule e.g.
> > +user/mediate                 #allow mediation of any user
> > +user/mediate/bob       #allow mediation of user 'bob'
> > Or possibly
> > +user/mediate/username/bob                 #allow mediation of user
> > 'bob'
> > +user/mediate/usertype/editor                               #allow
> > mediation of editor users
> >
> > I haven't read the SWORD specs on a while - and don't know whether
> > this is allowed.
> > I think this is an extension of the current functionality - and
> > possibly should be treated as an enhancement.
> >
> > Cheers,
> > John
> >
> >
> > From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-
> > bounc
> > es@ecs.soton.ac.uk] On Behalf Of Newman D.R. via Eprints-tech
> > Sent: 07 January 2019 17:36
> > To: eprints-tech@ecs.soton.ac.uk; John Salter <J.Salter@leeds.ac.uk
> > >;
> > Fran Callaghan <fran.callaghan@dcu.ie>
> > Subject: Re: [EP-tech] Error whilst depositing via SWORD
> >
> > Hi John / Fran,
> >
> > I believe I have made the appropriate tweaks needed in EPrints
> > 3.4's
> > perl_lib/EPrints/Apache/CRUD.pm and this seems to fix the issue
> > from
> > my testing.  You will need to set an extra role for the user that
> > is
> > going to submit "on behalf of" other users.  This permission is:
> >
> > +user/mediate
> >
> > I will endeavour to post the updated version to GitHub soon,
> > assuming
> > it is not too different to the version I was working against.
> >  However, if you want to make the changes yourself, there are only
> > three places in CRUD.pm that need fixed (see below).  I am assuming
> > this is on a development instance you are working on, as I would
> > not
> > be 100% confident this will not have any side effects.  John
> > thoughts?
> >
> > Regards
> >
> > David Newman
> >
> > # 1. sub handler
> > - my( $rc, $owner ) = on_behalf_of( $repo, $r, $user );
> > + my( $rc, $owner ) = $self->on_behalf_of( $user );
> >
> >
> > # 2. sub on_behalf_of
> > - my( $repo, $r, $user ) = @_;
> > + my( $self, $user ) = @_;
> >
> > - my $err = {
> > - status => HTTP_FORBIDDEN,
> > - href => "https://emea01.safelinks.protection.outlook.com/?url=htt
> > p%3A%2F%2Fpurl.org%2Fnet%2Fsword%2Ferror%2FTargetOwnerUnknown&amp;d
> > ata=01%7C01%7Cdrn%40ecs.soton.ac.uk%7Ca07a18eb5ca045ced87b08d675576
> > 43f%7C4a5378f929f44d3ebe89669d03ada9d8%7C1&amp;sdata=i5sdd8FVlS9Tsr
> > XRa1vY5FQHJt53jHdLZS57wNyPxgk%3D&amp;reserved=0",
> > - summary => "Target user unknown or no permission to act on-
> > behalf-
> > of",
> > - };
> > + my $r = $self->request;
> > +       my $repo = $self->repository;
> >
> >   my $on_behalf_of =
> >   $r->headers_in->{'On-Behalf-Of'} || # SWORD 2.0
> > $r->headers_in->{'X-On-Behalf-Of'}; # SWORD 1.3
> >
> >         return( OK, $user ) if !$on_behalf_of;
> >
> >   my $owner = $repo->user_by_username( $on_behalf_of );
> >
> > - return sword_error($repo, $r, %$err )
> > + return ( HTTP_FORBIDDEN, undef )
> >   if !defined $owner;
> > - return sword_error($repo, $r, %$err )
> > + return ( HTTP_FORBIDDEN, undef )
> >   if !$user->allow( "user/mediate", $owner );
> >
> >   return( OK, $owner );
> >
> >
> > # 3. sub servicedocument
> >   my $user = $repo->current_user;
> >   EPrints->abort( "unprotected" ) if !defined $user; # Rewrite
> > foobar
> > - my $on_behalf_of = on_behalf_of( $repo, $r, $user );
> > - if( $on_behalf_of->{status} != OK )
> > + my ( $status, $on_behalf_of ) = $self->on_behalf_of( $user );
> > + if( $status != OK )
> >   {
> > - return sword_error( $repo, $r, %$on_behalf_of );
> > + return $self->sword_error(
> > + status => HTTP_FORBIDDEN,
> > + href => "https://emea01.safelinks.protection.outlook.com/?url=htt
> > p%3A%2F%2Fpurl.org%2Fnet%2Fsword%2Ferror%2FTargetOwnerUnknown&amp;d
> > ata=01%7C01%7Cdrn%40ecs.soton.ac.uk%7Ca07a18eb5ca045ced87b08d675576
> > 43f%7C4a5378f929f44d3ebe89669d03ada9d8%7C1&amp;sdata=i5sdd8FVlS9Tsr
> > XRa1vY5FQHJt53jHdLZS57wNyPxgk%3D&amp;reserved=0",
> > +                        summary => "Target user unknown or no
> > permission to act on-behalf-of",
> > + );
> >   }
> > - $on_behalf_of = $on_behalf_of->{on_behalf_of};
> >
> >
> >
> > On Mon, 2019-01-07 at 16:30 +0000, John Salter via Eprints-tech
> > wrote:
> > Hi Fran,
> > It would depend on the CRIS system, and local policy: is knowing
> > who
> > the depositing author is from within EPrints important?
> >
> > You could create a 'CRIS' account - and all deposits would be made
> > by
> > this account (if the CRIS system allows this).
> >
> > I think both the Pure and the Symplectic connectors can do
> > something
> > similar to this - so it might be worth pursuing.
> >
> > If I get a chance I'll take a look at the module tonight.
> > Would you be in a position to test a proposed update to the file
> > this
> > week?
> >
> > Cheers,
> > John
> > From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-
> > bounc
> > es@ecs.soton.ac.uk] On Behalf Of Fran Callaghan via Eprints-tech
> > Sent: 07 January 2019 16:08
> > To: eprints-tech@ecs.soton.ac.uk
> > Subject: Re: [EP-tech] Error whilst depositing via SWORD
> >
> > Hi John,
> >
> > The depositing system is our CRIS. Would this make sense in so far
> > as
> > it would be making deposits "on behalf of" genuine researchers?
> > Does
> > the depositing system need to make this explicit in the first
> > place?
> > Can't it just deposit with a different author name?
> >
> > Thanks all,
> >
> > Fran Callaghan
> >
> >
> > On Mon, 7 Jan 2019 at 15:38, John Salter <J.Salter@leeds.ac.uk>
> > wrote:
> > Hi Fran,
> > Taking a quick look at the code, I think the issue is that in the
> > CRUD module, there are a couple of instances where the
> > 'sword_error'
> > is called as a raw function , rather than an object method e.g.:
> > Normal working:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > github.com%2Feprints%2Feprints%2Fblob%2F3.3%2Fperl_lib%2FEPrints%2F
> > Apache%2FC&amp;data=01%7C01%7Cdrn%40ecs.soton.ac.uk%7Ca07a18eb5ca04
> > 5ced87b08d67557643f%7C4a5378f929f44d3ebe89669d03ada9d8%7C1&amp;sdat
> > a=bQtpgQtsi7qCR2mggNu%2BGuLI6f%2FPBx6jP6spydPh88A%3D&amp;reserved=0
> > RUD.pm#L432-L436
> >
> > Function call in servicedocument function:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > github.com%2Feprints%2Feprints%2Fblob%2F3.3%2Fperl_lib%2FEPrints%2F
> > Apache%2FC&amp;data=01%7C01%7Cdrn%40ecs.soton.ac.uk%7Ca07a18eb5ca04
> > 5ced87b08d67557643f%7C4a5378f929f44d3ebe89669d03ada9d8%7C1&amp;sdat
> > a=bQtpgQtsi7qCR2mggNu%2BGuLI6f%2FPBx6jP6spydPh88A%3D&amp;reserved=0
> > RUD.pm#L1742-L1745
> > and 'on_behalf_of' function:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > github.com%2Feprints%2Feprints%2Fblob%2F3.3%2Fperl_lib%2FEPrints%2F
> > Apache%2FC&amp;data=01%7C01%7Cdrn%40ecs.soton.ac.uk%7Ca07a18eb5ca04
> > 5ced87b08d67557643f%7C4a5378f929f44d3ebe89669d03ada9d8%7C1&amp;sdat
> > a=bQtpgQtsi7qCR2mggNu%2BGuLI6f%2FPBx6jP6spydPh88A%3D&amp;reserved=0
> > RUD.pm#L1838-L1862
> >
> > This issue will only become apparent when you're doing a SWORD
> > deposit using the 'on-behalf-of' header.
> > I think it may have been present for ~7 years, when the first line
> > of
> > the sword_error function was changed from
> > my( $repo, $r, %opts ) = @_;
> > to
> > my( $self, %opts ) = @_;
> >
> > I think it's more than a 5-minute job to fix properly - I need to
> > get
> > into the code a bit more to understand what was changed - and how
> > to
> > resolve it.
> >
> > I'll log it in GitHub and let you know try and come up with a
> > solution - unless anyone else fancies having a  go..?
> >
> > Cheers,
> > John
> >
> >
> > From: eprints-tech-bounces@ecs.soton.ac.uk [mailto:eprints-tech-
> > bounc
> > es@ecs.soton.ac.uk] On Behalf Of Fran Callaghan via Eprints-tech
> > Sent: 07 January 2019 14:50
> > To: eprints-tech@ecs.soton.ac.uk
> > Subject: [EP-tech] Error whilst depositing via SWORD
> >
> > Hi All,
> >
> > We have a third party depositing via SWORD. They're getting a
> > generic
> > 500 message back but when I lookup the error_log corresponding to
> > the
> > time of the test I can see this message...
> >
> > [Mon Jan 07 13:46:18.179171 2019] [perl:error] [pid 10713] [client
> > X.X.X.X] Can't locate object method "repository" via package
> > "EPrints::Repository" at
> > /opt/eprints3/perl_lib/EPrints/Apache/CRUD.pm line 1977.\n
> >
> > Any ideas what's wrong with CRUD.pm? Or is it a problem with the
> > syntax of the deposit? I had expected SWORD to be pretty much plug
> > and play (actually not even 'plug' since the documentation says it
> > is
> > configured by default).
> >
> > **NOTE: I have X'd out the client IP address, it's a genuine IP in
> > the original message
> >
> > Thanks all,
> > Fran Callaghan
> >
> >
> > Séanadh Ríomhphoist/Email Disclaimer
> > Tá an ríomhphost seo agus aon chomhad a sheoltar leis faoi rún agus
> > is lena úsáid ag an seolaí agus sin amháin é. Is féidir tuilleadh a
> > léamh anseo.
> > This e-mail and any files transmitted with it are confidential and
> > are intended solely for use by the addressee. Read more here.
> >
> >
> >
> >
> >
> >
> > Séanadh Ríomhphoist/Email Disclaimer
> > Tá an ríomhphost seo agus aon chomhad a sheoltar leis faoi rún agus
> > is lena úsáid ag an seolaí agus sin amháin é. Is féidir tuilleadh a
> > léamh anseo.
> > This e-mail and any files transmitted with it are confidential and
> > are intended solely for use by the addressee. Read more here.
> >
> >
> >
> >
> >
> > *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprint
> > s-
> > tech
> > *** Archive: https://emea01.safelinks.protection.outlook.com/?url=h
> > ttp%3A%2F%2Fwww.eprints.org%2Ftech.php%2F&amp;data=01%7C01%7Cdrn%40
> > ecs.soton.ac.uk%7Ca07a18eb5ca045ced87b08d67557643f%7C4a5378f929f44d
> > 3ebe89669d03ada9d8%7C1&amp;sdata=oz9jIFR54KQApKOum0srBOaMNxYViF81vM
> > r8YvqbJak%3D&amp;reserved=0
> > *** EPrints community wiki: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Femea01.safelinks.protection.out&amp;data=01%7C01%7C%7C35d31d531bb54032d82e08d6755aa94f%7C4a5378f929f44d3ebe89669d03ada9d8%7C1&amp;sdata=aR%2BllpERJ0PxcPcFJvrDDMZ1NYPANLSM4nwpbnJFt1g%3D&amp;reserved=0
> > look.com/?url=http%3A%2F%2Fwiki.eprints.org%2F&amp;data=01%7C01%7Cd
> > rn%40ecs.soton.ac.uk%7Ca07a18eb5ca045ced87b08d67557643f%7C4a5378f92
> > 9f44d3ebe89669d03ada9d8%7C1&amp;sdata=cLc8BsZSsNzQGsEk29GjVAmQrncUH
> > K92pyvqmrOCflk%3D&amp;reserved=0
> > *** EPrints developers Forum: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Femea01.safelinks.protection.o&amp;data=01%7C01%7C%7C35d31d531bb54032d82e08d6755aa94f%7C4a5378f929f44d3ebe89669d03ada9d8%7C1&amp;sdata=E89eNg7Z671z173%2FyYy08juMeIbC%2B6su1YNq%2BGv2p9Q%3D&amp;reserved=0
> > utlook.com/?url=http%3A%2F%2Fforum.eprints.org%2F&amp;data=01%7C01%
> > 7Cdrn%40ecs.soton.ac.uk%7Ca07a18eb5ca045ced87b08d67557643f%7C4a5378
> > f929f44d3ebe89669d03ada9d8%7C1&amp;sdata=oV3VM5vptcFobrfzEZwVoq3YAb
> > jRtiMmGjfRx1dGL18%3D&amp;reserved=0
> *** Options: http://mailman.ecs.soton.ac.uk/mailman/listinfo/eprints-
> tech
> *** Archive: https://emea01.safelinks.protection.outlook.com/?url=htt
> p%3A%2F%2Fwww.eprints.org%2Ftech.php%2F&amp;data=01%7C01%7Cdrn%40ecs.
> soton.ac.uk%7Ca07a18eb5ca045ced87b08d67557643f%7C4a5378f929f44d3ebe89
> 669d03ada9d8%7C1&amp;sdata=oz9jIFR54KQApKOum0srBOaMNxYViF81vMr8YvqbJa
> k%3D&amp;reserved=0
> *** EPrints community wiki: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Femea01.safelinks.protection.outlo&amp;data=01%7C01%7C%7C35d31d531bb54032d82e08d6755aa94f%7C4a5378f929f44d3ebe89669d03ada9d8%7C1&amp;sdata=KRD%2FON5C%2BBTT3eDlRt23jRv3nWcrZDTkQ2W0pUWgvV0%3D&amp;reserved=0
> ok.com/?url=http%3A%2F%2Fwiki.eprints.org%2F&amp;data=01%7C01%7Cdrn%4
> 0ecs.soton.ac.uk%7Ca07a18eb5ca045ced87b08d67557643f%7C4a5378f929f44d3
> ebe89669d03ada9d8%7C1&amp;sdata=cLc8BsZSsNzQGsEk29GjVAmQrncUHK92pyvqm
> rOCflk%3D&amp;reserved=0
> *** EPrints developers Forum: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Femea01.safelinks.protection.out&amp;data=01%7C01%7C%7C35d31d531bb54032d82e08d6755aa94f%7C4a5378f929f44d3ebe89669d03ada9d8%7C1&amp;sdata=aR%2BllpERJ0PxcPcFJvrDDMZ1NYPANLSM4nwpbnJFt1g%3D&amp;reserved=0
> look.com/?url=http%3A%2F%2Fforum.eprints.org%2F&amp;data=01%7C01%7Cdr
> n%40ecs.soton.ac.uk%7Ca07a18eb5ca045ced87b08d67557643f%7C4a5378f929f4
> 4d3ebe89669d03ada9d8%7C1&amp;sdata=oV3VM5vptcFobrfzEZwVoq3YAbjRtiMmGj
> fRx1dGL18%3D&amp;reserved=0