[EP-tech] Error in exception handling in EPrints::Repository::call()

[Florian Heß]

Hi EPrints developers,

I discovered that EPrints::Repository::call() handles exceptions in a 
pretty bogus way due to a plain abuse of exit(). Indeed I cannot think 
of a valid usage scenario for exit() nowadays, I just hope you refrain 
from using it in contemporary coding. :-)

The line to blame is 
https://github.com/eprints/eprints/blob/3.3/perl_lib/EPrints/Repository.pm#L1735

So, if ever a user-configured routine throws an exception or dies from 
whatever reason, this is ignored, the error message is printed to 
nowhere I guess, rendering ModPerl to catch the exit-call and just reset 
$@ to its own message in the end: "ModPerl::Util::exit: (120000) exit 
was called at /usr/local/eprints/perl_lib_apache2/EPrints/Repository.pm 
line 1735".

I put an eval around $doc->permit(), forcing redirect to log in, which 
is how I have approached that bug.

If the user-configured routine in question is 
"can_request_view_document", failure of which might result in accidental 
leakage of embargoed documents and yield legal consequences for the 
hosting institution, because the document requested is delivered even if 
it was not meant to be. Apparently the PerlAccessHandler defined in 
EPrints::Apache::Rewrite aborts and things proceed as it was not defined 
at all.

So whoever has migrated EPrints to Apache 2.4, they should urgently 
check if restricted documents have since become accidentally accessible 
without login.

I think that simply replacing print by warn is not enough. Although I 
would assume that everything written to STDERR gets logged, this does 
not seem to be the case at our site.

At any rate, I will be glad if you patch the version available for the 
public.


Not to forget a note concerning the actual error:

Without my debugging modification of core code, I could never have found 
the real exception which reads 'Can't locate object method "remote_ip" 
via package "Apache2::Connection"'. This looks like an apache 2.4 novum.
Anyway, this has been fixed, or rather commented out, in the github repo 
3 years ago: 
https://github.com/eprints/eprints/commit/26e97fc3dbaa28e89e7ffbe0e6f8eedbfc7804cd#diff-e66de7bfe02fc8b3b7c562fa42b11658. 
Unfortunately this is useless when you update an existing EPrints. All 
code from lib/defaultcfg does not get updated automatically, but how 
would you know?


Regards,
Florian

-- 
UB Heidelberg (Altstadt)
Plöck 107-109, 69117 HD
Abt. Informationstechnik
http://www.ub.uni-heidelberg.de/