[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[EP-tech] Error in exception handling in EPrints::Repository::call()
- Subject: [EP-tech] Error in exception handling in EPrints::Repository::call()
- From: hess at ub.uni-heidelberg.de (Florian Heß)
- Date: Wed, 29 Nov 2017 17:48:28 +0100
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
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
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
So whoever has migrated EPrints to Apache 2.4, they should urgently
check if restricted documents have since become accidentally accessible
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
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:
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?
UB Heidelberg (Altstadt)
Pl?ck 107-109, 69117 HD