Bug 39160

Summary: Mojolicious::Plugin::OAuth2 is loaded suboptimally
Product: Koha Reporter: David Cook <dcook>
Component: Architecture, internals, and plumbingAssignee: David Cook <dcook>
Status: Needs Signoff --- QA Contact: Testopia <testopia>
Severity: trivial    
Priority: P5 - low CC: jake.deery, magnus
Version: Main   
Hardware: All   
OS: All   
GIT URL: Change sponsored?: ---
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
Circulation function:
Attachments: Bug 39160: Use optimal Mojolicious plugin name

Description David Cook 2025-02-19 02:26:23 UTC
This is a deep cut, but the following line is not optimal:
$self->plugin( 'Mojolicious::Plugin::OAuth2' => $oauth_configuration );

Mojolicious will first try to load that as Mojolicious::Plugin::Mojolicious::Plugin::OAuth2 before it realises that we've already loaded Mojolicious::Plugin::OAuth2 earlier in Koha::REST::V1.

I reckon that should say:
$self->plugin( 'OAuth2' => $oauth_configuration );

--

In the grand scheme of things, it's not a big deal, but we can save ourselves 26 system calls by changing 1 line.
Comment 1 David Cook 2025-02-19 06:00:01 UTC
Created attachment 178304 [details] [review]
Bug 39160: Use optimal Mojolicious plugin name

This change uses "OAuth2" instead of "Mojolicious::Plugin::OAuth2"
when setting the plugin, so that Mojolicious can find the plugin
faster.

Test plan:
0. Apply the patch
1. koha-plack --restart kohadev
2. Run through "Testing SSO" from the Koha Wiki
3. Confirm that you can log into Koha using the Keycloak OIDC
Comment 2 David Cook 2025-02-19 06:01:36 UTC
If you *really* want to confirm this does what I say it does, you're going to have to use "strace" to examine the kernel syscalls the starman worker is making when it starts up.

Specifically, you'll be looking to make sure that it doesn't do things like this:
newfstatat(AT_FDCWD, "/usr/local/lib/site_perl/Mojolicious/Plugin/Mojolicious/Plugin/OAuth2.pm", 0x7ffd205204e0, 0) = -1 ENOENT (No such file or directory)
Comment 3 Magnus Enger 2025-04-01 09:23:22 UTC
When spinning up ktd with --sso to test this, I was getting this:

kohadev-sso-1        | Unknown option: '--proxy'
kohadev-sso-1        | Possible solutions: --proxy-headers, --proxy-protocol-enabled, --proxy-trusted-addresses
kohadev-sso-1        | Try 'kc.sh start-dev --help' for more information on the available options.
kohadev-sso-1 exited with code 2

It looks like changing koha-testing-docker from this:

        command:
            - start-dev
            - --proxy=edge
            - --http-port=8082  
            - --http-relative-path=/auth

to this:

        command:
            - start-dev
            - --http-port=8082  
            - --http-relative-path=/auth

might have solved it. Not sure if that will create trouble later, though.
Comment 4 Magnus Enger 2025-04-01 12:04:34 UTC
I *think* I did all the steps in "Testing SSO", but when I try to sign in to the OPAC, I get "No configuration found for your provider", even though I do have a configuration called "test" and the "Log in with Test" link points to http://localhost:8080/api/v1/public/oauth/login/test/opac. 

The error comes from this code:

    unless ( $provider_config && $provider_config->{authorize_url} ) {
        my $error = "No configuration found for your provider";
        return $c->redirect_to( $uri . "?auth_error=$error" );
    }

If I dump the $provider_config I get this: 

$VAR1 = {
          'scope' => 'openid email',
          'key' => 'kohaoidc',
          'secret' => 'tYgrpU0KXt2EtPu5b437Oj6viMImMoqK',
          'well_known_url' => 'http://localhost:8082/auth/realms/test/.well-known/openid-configuration'
        };

So there is no authorize_url there, but I am not sure why.
Comment 5 David Cook 2025-04-01 22:26:20 UTC
Hmm sounds unrelated to this change.

Sounds like we might need to tweak the Keycloak Docker Compose config. We must be using "latest" and it must have a change.

As for your error, I think you need to use http://sso:8082/auth/realms/test/.well-known/openid-configuration rather than http://localhost:8082/auth/realms/test/.well-known/openid-configuration because the Keycloak isn't on the same "localhost" as Koha.
Comment 6 David Cook 2025-04-02 22:11:07 UTC
Just noticed that Jake updated the "Testing SSO" to use "localhost" instead of "sso" as the hostname, but surely that can't be right.

I was writing an OIDC integration against Keycloak for another app just yesterday and  at least when testing using Keycloak in a different container, it needs to be an address or hostname for the Keycloak container reachable in the same way by both the Koha container and the end user's browser.