Bug 34293

Summary:	ILS-DI returns 200 instead of 403 for unauthorized requests
Product:	Koha	Reporter:	David Cook <dcook>
Component:	Web services	Assignee:	Bugs List <koha-bugs>
Status:	NEW ---	QA Contact:	Testopia <testopia>
Severity:	enhancement
Priority:	P5 - low
Version:	Main
Hardware:	All
OS:	All
Change sponsored?:	---	Patch complexity:	---
Documentation contact:		Documentation submission:
Text to go in the release notes:		Version(s) released in:
Circulation function:

Description David Cook 2023-07-17 02:53:31 UTC

We had a third-party hitting the ILS-DI API and in the logs it said 200, but they were actually getting the "Unauthorized IP address" message.

It seems to me that we should have the ILS-DI API reply with 403 in that situation, so that Koha sysadmins can see that the requests are failing.

This could also be useful for security monitoring.

Comment 1 David Cook 2023-07-17 03:16:11 UTC

Ah right... we can't do that without changing Apache because otherwise it'll use the the generic Koha HTML 403 error document...

Comment 2 David Cook 2023-07-17 03:16:22 UTC

(In reply to David Cook from comment #1)
> Ah right... we can't do that without changing Apache because otherwise it'll
> use the the generic Koha HTML 403 error document...

This is something I bumped into at https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=31982&attachment=142662

Comment 3 David Cook 2023-07-17 03:25:46 UTC

Actually this one is harder because the error message is coming from the ErrorDocument Plack Middleware and not Apache...

Comment 4 David Cook 2023-07-17 03:40:07 UTC

So I think this might be impossible without removing Plack::Middleware::ErrorDocument or mounting ilsdi.pl as its own Plack app. 

The latter could be doable using the following:

my $ilsdi_app = Plack::App::WrapCGI->new(script => "/path/to/script.pl")->to_app;

mount '/opac/ilsdi.pl' => $ilsdi_app;

Plack::App::WrapCGI is what's used under the hood by Plack::App::CGIBin.

The path to script would depend on whether or not it's a DEV_INSTALL, but it would be doable.

--

But it might not be worth it just to get better HTTP codes...