Bug 40736 - OAuth/OIDC authentication logs error message when CGISESSID is missing
Summary: OAuth/OIDC authentication logs error message when CGISESSID is missing
Status: Needs Signoff
Alias: None
Product: Koha
Classification: Unclassified
Component: REST API (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: David Cook
QA Contact: Testopia
URL:
Keywords:
Depends on: 33675
Blocks:
  Show dependency treegraph
 
Reported: 2025-09-01 10:45 UTC by Lari Taskula
Modified: 2025-09-29 11:31 UTC (History)
3 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Crowdfunding goal: 0
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
OPAC error after being redirected back from Okta IdP - URL details redacted (51.39 KB, image/png)
2025-09-22 05:57 UTC, Alex Buckley
Details
Bug 40736: Gracefully handle missing CGISESSID cookie (1.75 KB, patch)
2025-09-26 02:28 UTC, David Cook
Details | Diff | Splinter Review
Bug 40736: Gracefully handle missing CGISESSID cookie (1.80 KB, patch)
2025-09-29 11:28 UTC, Lari Taskula
Details | Diff | Splinter Review
Bug 40736: Restore commented out tests (3.62 KB, patch)
2025-09-29 11:28 UTC, Lari Taskula
Details | Diff | Splinter Review
Bug 40736: Add test (1.30 KB, patch)
2025-09-29 11:28 UTC, Lari Taskula
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Lari Taskula 2025-09-01 10:45:06 UTC
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
Comment 1 Alex Buckley 2025-09-22 04:26:51 UTC
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.
Comment 2 David Cook 2025-09-22 05:29:59 UTC
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.
Comment 3 David Cook 2025-09-22 05:30:19 UTC
(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?
Comment 4 David Cook 2025-09-22 05:30:35 UTC
Lari: Which version of Koha are you using?
Comment 5 Alex Buckley 2025-09-22 05:54:18 UTC
(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.
Comment 6 Alex Buckley 2025-09-22 05:57:35 UTC
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')
Comment 7 Lari Taskula 2025-09-22 10:11:47 UTC
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.
Comment 8 David Cook 2025-09-23 06:30:14 UTC
(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.
Comment 9 David Cook 2025-09-23 06:33:22 UTC
(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.
Comment 10 David Cook 2025-09-26 02:09:27 UTC
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.
Comment 11 David Cook 2025-09-26 02:28:29 UTC
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"
Comment 12 David Cook 2025-09-26 02:29:37 UTC
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.
Comment 13 David Cook 2025-09-26 02:36:06 UTC
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 :/.
Comment 14 David Cook 2025-09-26 02:46:14 UTC
I just double-checked 24.11 and its OIDC is working well with Keycloak for me as well.
Comment 15 Alex Buckley 2025-09-26 02:51:53 UTC
(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!
Comment 16 Lari Taskula 2025-09-29 11:28:29 UTC
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>
Comment 18 Lari Taskula 2025-09-29 11:28:33 UTC
Created attachment 187033 [details] [review]
Bug 40736: Add test

To test:
1. prove t/db_dependent/api/v1/idp.t
Comment 19 Lari Taskula 2025-09-29 11:31:44 UTC
(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.