Summary: | Mojolicious::Plugin::OAuth2 is loaded suboptimally | ||
---|---|---|---|
Product: | Koha | Reporter: | David Cook <dcook> |
Component: | Architecture, internals, and plumbing | Assignee: | 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
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 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) 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. 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. 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. 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. |