Our API error logs contain multiple instances of the following error > [ERROR] Can't call method "value" on an undefined value at /usr/share/koha/lib/Koha/REST/V1/OAuth/Client.pm line 100. Client.pm:100 is > $state = Koha::Token->new->generate_csrf( { session_id => $c->req->cookie('CGISESSID')->value } ); This happens when a web crawler (Googlebot in our case) navigates to OAuth/OIDC login API endpoint, and Koha attempts to generate them a new CSRF token but is unable to due to missing CGISESSID cookie. To replicate: 1. Have an identity provider <provider code> defined under Administration > Identity providers 2. On a fresh browser session (clear cookies), 3. Navigate to https://yourkoha/api/v1/public/oauth/login/<provider code>/opac 4. Observe [ERROR] Can't call method "value" on an undefined value at /usr/share/koha/lib/Koha/REST/V1/OAuth/Client.pm line 100. in plack-api-error.log
Hi, Thank you for reporting this. We are also encountering this error when human users are trying to log into the Koha OPAC (24.11.07) via OIDC from Chrome.
While I think coding a fix for that error message would be a good idea, you need to have a Koha session in order to generate the state value for the OIDC login. I suppose you could argue that the endpoint could generate a CGISESSID cookie if it's missing, but there shouldn't be a scenario where it's missing when logging in, since you should be navigating to it from the Koha UI.
(In reply to Alex Buckley from comment #1) > Hi, > > Thank you for reporting this. We are also encountering this error when human > users are trying to log into the Koha OPAC (24.11.07) via OIDC from Chrome. I thought that you said that it was working in Chrome but not in Firefox and only for Okta?
Lari: Which version of Koha are you using?
(In reply to David Cook from comment #3) > (In reply to Alex Buckley from comment #1) > > Hi, > > > > Thank you for reporting this. We are also encountering this error when human > > users are trying to log into the Koha OPAC (24.11.07) via OIDC from Chrome. > > I thought that you said that it was working in Chrome but not in Firefox and > only for Okta? Thanks for asking David! This is a new error we have recently encountered, also for Okta (the Koha IdP is configured to use protocol=OIDC). So separate to the login/logout/login we have inquired about. This error is not consistent, but the workflow is: - Start Chrome. - Go to either the Koha OPAC or staff client login page. - Click the 'Log in with Okta IdP' button. - You're re-directed to Okta. - After logging in, you're redirected back to Koha with an internal server error - screenshot attached from OPAC. I'm warning out the following (below this line https://git.koha-community.org/Koha-community/Koha/src/commit/2778a49fb16be18fc7ee0bc86983f8f9f0e16902/Koha/REST/V1/OAuth/Client.pm#L83 ): use Data::Dumper; warn Dumper($c->req->cookie('CGISESSID')); And in plack-api-error.log the $c->req->cookie('CGISESSID') is NULL and the error is thrown: [2025/09/22 05:39:33] [WARN] $VAR1 = undef; [2025/09/22 05:39:33] [ERROR] Can't call method "value" on an undefined value at /usr/share/koha/lib/Koha/REST/V1/OAuth/Client.pm line 86.
Created attachment 186651 [details] OPAC error after being redirected back from Okta IdP - URL details redacted Error thrown associated with an undef $c->req->cookie('CGISESSID')
Hi David, (In reply to David Cook from comment #4) > Lari: Which version of Koha are you using? 25.05.02 and 24.11.06 (In reply to David Cook from comment #2) > While I think coding a fix for that error message would be a good idea, you > need to have a Koha session in order to generate the state value for the > OIDC login. > I suppose you could argue that the endpoint could generate a CGISESSID > cookie if it's missing, but there shouldn't be a scenario where it's missing > when logging in, since you should be navigating to it from the Koha UI. Would there be any downsides of having the endpoint generate the CGISESSID in case it is missing? Out of curiosity wouldn't it be useful to do so for external applications wanting to OIDC-authenticate an user to Koha to gain access to its authorized REST API endpoints? By bare minimum we have to handle the exception by checking the existence of CGISESSID and responding with a HTTP 400 (bad request) in case it is missing, and perhaps log a warning instead of an error, if the logging of this event is wanted in the first place.
(In reply to Alex Buckley from comment #5) > This error is not consistent, but the workflow is: > > - Start Chrome. > - Go to either the Koha OPAC or staff client login page. > - Click the 'Log in with Okta IdP' button. > - You're re-directed to Okta. > - After logging in, you're redirected back to Koha with an internal server > error - screenshot attached from OPAC. Ok I'll see if I can reproduce. I was already looking at SSO stuff today so it's on the mind.
(In reply to Lari Taskula from comment #7) > (In reply to David Cook from comment #4) > > Lari: Which version of Koha are you using? > 25.05.02 and 24.11.06 Cool I have a 24.11 I can test off easily, and I'll check main as well. > (In reply to David Cook from comment #2) > Would there be any downsides of having the endpoint generate the CGISESSID > in case it is missing? Out of curiosity wouldn't it be useful to do so for > external applications wanting to OIDC-authenticate an user to Koha to gain > access to its authorized REST API endpoints? I'd say that's actually a CSRF security vulnerability. > By bare minimum we have to handle the exception by checking the existence of > CGISESSID and responding with a HTTP 400 (bad request) in case it is > missing, and perhaps log a warning instead of an error, if the logging of > this event is wanted in the first place. Yeah, certainly needs some code improvement there.
Okies... I'm able to log into Keycloak using Chrome on main (e.g. 25.06.00.018). Now trying to just direct link to http://localhost:8080/api/v1/public/oauth/login/test/opac In the browser, I see: {"errors":[{"message":"Internal Server Error.","path":"\/"}],"status":500} In /var/log/koha/kohadev/plack-api-error.log, I see: [2025/09/26 02:08:28] [ERROR] Can't call method "value" on an undefined value at /kohadevbox/koha/Koha/REST/V1/OAuth/Client.pm line 100.
Created attachment 186950 [details] [review] Bug 40736: Gracefully handle missing CGISESSID cookie This change makes the REST API gracefully handle a missing CGISESSID when trying to do an OAuth/OIDC login by direct linking. Test plan: 0. Apply the patch and koha-plack --restart kohadev 1. Set up an OpenID Connect client using the wiki https://wiki.koha-community.org/wiki/Testing_SSO 2. In an incognito/private window, try directly logging in with the following URL: http://localhost:8080/api/v1/public/oauth/login/test/opac 3. Note that you're redirected to opac-user.pl with an auth error message of "No user session found" 4. Close the incognito/private window 5. In an incognito/private window, try directly logging in with the following URL: http://localhost:8081/api/v1/oauth/login/test/staff 6. Note that you're redirected to mainpage.pl with an auth error message of "No user session found"
This change will prevent the error message in plack-api-error.log and will instead show a Koha web page with a human friendly error message.
Alex: You'll still experience your problem but you'll get a prettier error message at least. To me, BZ 40736 is just about the API log getting filled up with errors unnecessarily. As for your issue, Alex... it's weird. Very weird. But unfortunately I do think it's a local issue. Your CGISESSID cookie is missing when it shouldn't be and you'll have to keep troubleshooting it locally I think :/.
I just double-checked 24.11 and its OIDC is working well with Keycloak for me as well.
(In reply to David Cook from comment #13) > Alex: You'll still experience your problem but you'll get a prettier error > message at least. > > To me, BZ 40736 is just about the API log getting filled up with errors > unnecessarily. > > As for your issue, Alex... it's weird. Very weird. But unfortunately I do > think it's a local issue. Your CGISESSID cookie is missing when it shouldn't > be and you'll have to keep troubleshooting it locally I think :/. Thanks David!(In reply to David Cook from comment #13) > Alex: You'll still experience your problem but you'll get a prettier error > message at least. > > To me, BZ 40736 is just about the API log getting filled up with errors > unnecessarily. > > As for your issue, Alex... it's weird. Very weird. But unfortunately I do > think it's a local issue. Your CGISESSID cookie is missing when it shouldn't > be and you'll have to keep troubleshooting it locally I think :/. Thanks for the patches and update David. Appreciate it!
Created attachment 187031 [details] [review] Bug 40736: Gracefully handle missing CGISESSID cookie This change makes the REST API gracefully handle a missing CGISESSID when trying to do an OAuth/OIDC login by direct linking. Test plan: 0. Apply the patch and koha-plack --restart kohadev 1. Set up an OpenID Connect client using the wiki https://wiki.koha-community.org/wiki/Testing_SSO 2. In an incognito/private window, try directly logging in with the following URL: http://localhost:8080/api/v1/public/oauth/login/test/opac 3. Note that you're redirected to opac-user.pl with an auth error message of "No user session found" 4. Close the incognito/private window 5. In an incognito/private window, try directly logging in with the following URL: http://localhost:8081/api/v1/oauth/login/test/staff 6. Note that you're redirected to mainpage.pl with an auth error message of "No user session found" Signed-off-by: Lari Taskula <lari.taskula@hypernova.fi>
Created attachment 187032 [details] [review] Bug 40736: Restore commented out tests Commented out by https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=143438 (or https://github.com/Koha-Community/Koha/commit/9c5f6e8c1772ecb1c2ec8c25d6d32010ce6c263b#diff-9e449131ec9eb973ff6a851c0fda9a426255591e3f579c79b047fb2763f33e80R275 ) To test: 1. prove t/db_dependent/api/v1/idp.t
Created attachment 187033 [details] [review] Bug 40736: Add test To test: 1. prove t/db_dependent/api/v1/idp.t
(In reply to Lari Taskula from comment #17) > Created attachment 187032 [details] [review] [review] > Bug 40736: Restore commented out tests While looking for existing tests, I found idp.t tests that were commented out by Bug 31378. I assume those comment-outs were accidentally pushed. This patch restores those tests.