EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #06984

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

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

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/