Bug 37286 - Fix REST API authentication when using Mojo apps
Summary: Fix REST API authentication when using Mojo apps
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: REST API (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Julian Maurice
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-07-09 11:40 UTC by Julian Maurice
Modified: 2024-07-09 23:31 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 37286: Fix REST API authentication when using Mojo apps (4.52 KB, patch)
2024-07-09 11:41 UTC, Julian Maurice
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Maurice 2024-07-09 11:40:17 UTC
Koha::REST::V1::Auth checks the request URL path and do various things depending on how it looks.
For instance, it allows everyone to access paths starting with "/api/v1/oauth/"

But because of how Koha::REST::V1 was written, when using mojolicious applications Koha::App::Intranet and Koha::App::Opac, paths had to add a path prefix ("/api"), which means the final path as seen by Koha::REST::V1::Auth looked like this: "/api/api/v1/oauth"

I said "had to", but actually there is another way that does not require this path manipulation and that's what this bug is about
Comment 1 Julian Maurice 2024-07-09 11:41:10 UTC
Created attachment 168644 [details] [review]
Bug 37286: Fix REST API authentication when using Mojo apps

Koha::REST::V1::Auth checks the request URL path and do various things
depending on how it looks.
For instance, it allows everyone to access paths starting with
"/api/v1/oauth/"

But because of how Koha::REST::V1 was written, when using mojolicious
applications Koha::App::Intranet and Koha::App::Opac, paths had to add a
path prefix ("/api"), which means the final path as seen by
Koha::REST::V1::Auth looked like this: "/api/api/v1/oauth".

I said "had to", but actually there is another way that does not require
this path manipulation and that's what this patch does:

Koha::REST::V1 now accepts a configuration parameter that allows to
change the base path for API routes, which allows
Koha::App::Plugin::RESTV1 (used by Koha::App::Intranet and
Koha::App::Opac) to generate the right routes.

This configuration parameter defaults to "/api/v1", so when outside of
Koha::App::Intranet and Koha::App::Opac (when using
debian/templates/plack.psgi for instance), the behavior is unchanged.

Test plan:
1. Do not apply the patch yet
2. Run `bin/intranet daemon -l http://*:8080`
3. Run `curl -i -d{} http://127.0.0.1:8080/api/v1/oauth/token`
   It should return a 403 error, with an error message "Authentication
   failure".
4. Stop `bin/intranet daemon -l http://*:8080` by hitting Ctrl-C on the
   terminal you started it
5. Apply the patch
6. Run `bin/intranet daemon -l http://*:8080` again
7. Run `curl -i -d{} http://127.0.0.1:8080/api/v1/oauth/token`
   This time it should return a 400 error with an error message saying
   the "grant_type" property is missing.
   This error is normal as we did not send any data in the POST request
   body, and seeing this means Koha allowed us to use that route because
   it recognized '/api/v1/oauth/' at the start of the URL path
8. You can do the same test with `bin/opac`