Bug 36102 - Protect login forms from CSRF attacks
Summary: Protect login forms from CSRF attacks
Status: RESOLVED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Jonathan Druart
QA Contact: Testopia
URL:
Keywords:
Depends on: 34478
Blocks: 36192 36084 36308 36349
  Show dependency treegraph
 
Reported: 2024-02-15 10:53 UTC by Jonathan Druart
Modified: 2024-04-17 08:49 UTC (History)
11 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Druart 2024-02-15 10:53:42 UTC

    
Comment 1 Jonathan Druart 2024-02-15 13:15:16 UTC
Please see branch security/bug_34478_svc for commits for this bug.

The login forms are covered, but I am facing a selenium failure during the installer that I am not able to fix.

See the commit message for more information.
Comment 2 Jonathan Druart 2024-02-15 14:08:31 UTC
See also second commit "Bug 36102: Fix 01-installation.t - WIP 2"
Comment 3 David Cook 2024-02-16 00:47:03 UTC
(In reply to Jonathan Druart from comment #1)
> Please see branch security/bug_34478_svc for commits for this bug.
> 
> The login forms are covered, but I am facing a selenium failure during the
> installer that I am not able to fix.
> 
> See the commit message for more information.

The login forms are looking good for normal staff and opac login. Thanks.

Just about to look at the selenium issue and the installer login..
Comment 4 David Cook 2024-02-16 00:48:20 UTC
How do you trigger the selenium failure? At the moment, it's looking OK for me.

prove ./t/db_dependent/selenium/01-installation.t
./t/db_dependent/selenium/01-installation.t .. ok
All tests successful.
Files=1, Tests=2,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.37 cusr  0.01 csys =  0.40 CPU)
Result: PASS
Comment 5 David Cook 2024-02-16 00:49:13 UTC
I just tried the following but still good:

cp debian/templates/plack.psgi /etc/koha/sites/kohadev/plack.psgi

sudo koha-plack --reload kohadev

prove ./t/db_dependent/selenium/01-installation.t
./t/db_dependent/selenium/01-installation.t .. ok
All tests successful.
Files=1, Tests=2,  0 wallclock secs ( 0.02 usr  0.00 sys +  0.41 cusr  0.06 csys =  0.49 CPU)
Result: PASS
Comment 6 David Cook 2024-02-16 00:52:50 UTC
The login at http://localhost:8081/cgi-bin/koha/installer/install.pl looks OK to me too.

Sorry but I couldn't find any problems? 

I run all of the above using the "bug_34478_svc" branch from the "security" repo.
Comment 7 Jonathan Druart 2024-02-16 11:22:49 UTC Comment hidden (obsolete)
Comment 8 Jonathan Druart 2024-02-16 11:25:40 UTC
To run selenium tests you can either use misc4dev/run_tests --run-selenium-tests only, or run them one by one.

However for 01-installation.t (and 00-onboarding.t) you need to DROP + CREATE + restart_all, and set env var KOHA_TESTING=1

The test is failing with the following error:
Error while executing command: no such element: Unable to locate element: //div[@id="installer-step3"]//a[contains(@href, "/installer/onboarding.pl")] at /usr/share/perl5/Selenium/Remote/Driver.pm line 411. at /usr/share/perl5/Selenium/Remote/Driver.pm line 356.

What's happening:
We are reaching "The form submission failed (Wrong CSRF token)" for op cud-addframeworks.
The CSRF check fails because userenv is not set, and so we are using "anonymous" (DEFA_SESSION_USERID from Koha::Token) instead of the DB user koha_kohadev.

I am a bit lost and missing the obvious, but there is something wrong happening: we are using userenv for the CSRF check in CGI->new, BUT userenv is set in get_template_and_user that is called after CGI instantiation.
Why is it working in the other situations but this one?

Why is it working when I run the installer using the UI but failing with selenium tests?

Putting it aside for now, I am out of ideas and I don't see the obvious. Help!
Comment 9 Jonathan Druart 2024-02-16 11:40:00 UTC
Something I should add: there is a weird FIXME already in the tests:

124     for (1..20){ # FIXME This is really ugly, but for an unknown reason the next submit_form is resubmitting the same form. So waiting for the next page to be effectively loaded

Which is the place where something is happening.
Comment 10 David Cook 2024-02-19 03:22:48 UTC
I'll try those steps you've suggested.

It may be unrelated, but I notice that security/bug_34478_svc is missing commits from bug 36098. In this upstream branch, currently the "File" driver will always be used - even for the web UI, because the "storage_method" change for Koha::Session::_get_session_params() wasn't done correctly.

(In reply to Jonathan Druart from comment #8)
> I am a bit lost and missing the obvious, but there is something wrong
> happening: we are using userenv for the CSRF check in CGI->new, BUT userenv
> is set in get_template_and_user that is called after CGI instantiation.
> Why is it working in the other situations but this one?

We need to *stop* using userenv for the CSRF check. We need to be using the actual session object. I have a local patch for bug 34478 that will fix this, but it relies on bug 36098. We need bug 36098 in bug 34478 before I can push that patch. 
 
> Why is it working when I run the installer using the UI but failing with
> selenium tests?

That's a good question. I'll investigate.
Comment 11 David Cook 2024-02-19 03:23:15 UTC
(In reply to David Cook from comment #10)
> We need to *stop* using userenv for the CSRF check. We need to be using the
> actual session object. I have a local patch for bug 34478 that will fix
> this, but it relies on bug 36098. We need bug 36098 in bug 34478 before I
> can push that patch. 

Until I do this, the self checkout is broken in bug 34478.
Comment 12 David Cook 2024-02-19 03:26:44 UTC
(In reply to Jonathan Druart from comment #8)
> To run selenium tests you can either use misc4dev/run_tests
> --run-selenium-tests only, or run them one by one.
> 
> However for 01-installation.t (and 00-onboarding.t) you need to DROP +
> CREATE + restart_all, and set env var KOHA_TESTING=1

kshell
sudo koha-mysql kohadev
drop database koha_kohadev;
create database koha_kohadev;
restart_all
export KOHA_TESTING=1
cp debian/templates/plack.psgi /etc/koha/sites/kohadev/plack.psgi

restart_all

prove ./t/db_dependent/selenium/01-installation.t
./t/db_dependent/selenium/01-installation.t ..
STRACE: /usr/share/perl5/Try/Tiny.pm:123 in Selenium::Remote::Driver::catch {...}
        /usr/share/perl5/Selenium/Remote/Driver.pm:361 in Try::Tiny::try
        (eval 351):1 in Selenium::Remote::Driver::__ANON__
        (eval 353):2 in Selenium::Remote::Driver::__ANON__
        /usr/share/perl5/Selenium/Remote/Driver.pm:1340 in Selenium::Remote::Driver::_execute_command
        /usr/share/perl5/Selenium/Remote/Driver.pm:1340 in (eval)
        ./t/db_dependent/selenium/01-installation.t:107 in Selenium::Remote::Driver::find_element

Error while executing command: no such element: Unable to locate element: //div[@class="alert alert-success"] at /usr/share/perl5/Selenium/Remote/Driver.pm line 411.
 at /usr/share/perl5/Selenium/Remote/Driver.pm line 356.
# Looks like your test exited with 255 before it could output anything.
./t/db_dependent/selenium/01-installation.t .. Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 2/2 subtests

Test Summary Report
-------------------
./t/db_dependent/selenium/01-installation.t (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 2 tests but ran 0.
Files=1, Tests=0, 28 wallclock secs ( 0.03 usr  0.00 sys +  1.26 cusr  0.04 csys =  1.33 CPU)
Result: FAIL
Comment 13 David Cook 2024-02-19 06:03:09 UTC
I've been swamped today, so I haven't had a chance to look at this much after all.

Looking at my issue with ./t/db_dependent/selenium/01-installation.t and it seems like I'm at the wrong page at the wrong time in the test... not sure that it's related to CSRF as I'm not seeing any CSRF errors even with all my logging dialled up to DEBUG...
Comment 14 Jonathan Druart 2024-02-19 15:51:34 UTC
(In reply to David Cook from comment #11)
> (In reply to David Cook from comment #10)
> > We need to *stop* using userenv for the CSRF check. We need to be using the
> > actual session object. I have a local patch for bug 34478 that will fix
> > this, but it relies on bug 36098. We need bug 36098 in bug 34478 before I
> > can push that patch. 
> 
> Until I do this, the self checkout is broken in bug 34478.

Added to 34478. Would have been better to ask there in the first place. Switching dependencies and adjusting remote branches, again.
Comment 15 Jonathan Druart 2024-02-19 16:04:23 UTC
(In reply to David Cook from comment #12)
> (In reply to Jonathan Druart from comment #8)
> > To run selenium tests you can either use misc4dev/run_tests
> > --run-selenium-tests only, or run them one by one.
> > 
> > However for 01-installation.t (and 00-onboarding.t) you need to DROP +
> > CREATE + restart_all, and set env var KOHA_TESTING=1
> 
> kshell
> sudo koha-mysql kohadev
> drop database koha_kohadev;
> create database koha_kohadev;
> restart_all
> export KOHA_TESTING=1
> cp debian/templates/plack.psgi /etc/koha/sites/kohadev/plack.psgi
> 
> restart_all

I don't think this is the place to debug or ask "how to run selenium tests".
Try --run-selenium-tests on master and confirm it works.

Also note that bug_34478_svc contains debug changes, you could try to revert them (ie. pick the file from master).
Comment 16 Jonathan Druart 2024-02-19 16:07:42 UTC
> (In reply to Jonathan Druart from comment #8)
> > I am a bit lost and missing the obvious, but there is something wrong
> > happening: we are using userenv for the CSRF check in CGI->new, BUT userenv
> > is set in get_template_and_user that is called after CGI instantiation.
> > Why is it working in the other situations but this one?
> 
> We need to *stop* using userenv for the CSRF check. We need to be using the
> actual session object. I have a local patch for bug 34478 that will fix
> this, but it relies on bug 36098. We need bug 36098 in bug 34478 before I
> can push that patch. 

If you knew that, why didn't you submit the patch somewhere? Why didn't you tell us we had to change how the CSRF token was generated? Maybe it's lost in a comment, but I also lost my Friday afternoon...

You sold the purpose of Koha::Session as "retrieve the session easily without using C4::Auth".
Comment 17 David Cook 2024-02-19 23:24:16 UTC
(In reply to Jonathan Druart from comment #16)
> If you knew that, why didn't you submit the patch somewhere? Why didn't you
> tell us we had to change how the CSRF token was generated? Maybe it's lost
> in a comment, but I also lost my Friday afternoon...

My apologies for the miscommunication. I think I emailed about it rather than adding a comment, so that might've made it harder to see. 

I'm not 100% sure that my patch will fix this scenario, but it might be related. I'll have to check.
Comment 18 David Cook 2024-02-19 23:26:47 UTC
(In reply to Jonathan Druart from comment #15)
> I don't think this is the place to debug or ask "how to run selenium tests".
> Try --run-selenium-tests on master and confirm it works.

I thought I was following your earlier instructions by running it on its own. I can certainly run it with --run-selenium-tests. 
 
> Also note that bug_34478_svc contains debug changes, you could try to revert
> them (ie. pick the file from master).

Ok. I'll take a look.
Comment 19 Jonathan Druart 2024-02-20 13:17:53 UTC
Two new commits added to the remote branch

Bug 36102: (follow-up) Add cud-login to the login form
Bug 36102: Do not keep op and csrf_token in param list after login - OPAC
Bug 36102: Generate a new sessionID if the existing one is invalid
Bug 36102: Remove cookie from the installer session

They need extensive review.

The selenium tests are still failing.

Additional there is a regression: at the end of the installer you are always getting "invalid csrf token" (not displayed on the UI, it says "session expired"). You need to login twice.
Comment 20 Jonathan Druart 2024-02-20 13:32:05 UTC
(In reply to Jonathan Druart from comment #19)
> Additional there is a regression: at the end of the installer you are always
> getting "invalid csrf token" (not displayed on the UI, it says "session
> expired"). You need to login twice.

Fixed with "Bug 36102: If CSRF check fails, try with anonymous" which feels quite ugly, but... why not?
Comment 21 David Cook 2024-02-20 23:21:58 UTC
Ok now I'm running "perl misc4dev/run_tests.pl --run-selenium-tests --koha-dir=/kohadevbox/koha" and I think I understand better now...

I see a failure with t/db_dependent/selenium/00-onboarding.t so I'll look at that first...
Comment 22 David Cook 2024-02-20 23:34:27 UTC
(In reply to David Cook from comment #21)
> Ok now I'm running "perl misc4dev/run_tests.pl --run-selenium-tests
> --koha-dir=/kohadevbox/koha" and I think I understand better now...
> 
> I see a failure with t/db_dependent/selenium/00-onboarding.t so I'll look at
> that first...

Hmm... something is weird here. It's failing only sporadically. Sometimes it fails and sometimes it succeeds...
Comment 23 David Cook 2024-02-21 00:03:05 UTC
Well the web UI installer is working at least.

I get the feeling the Selenium might be failing due to timeouts. At least on my machine...
Comment 24 David Cook 2024-02-21 00:06:01 UTC
(In reply to David Cook from comment #23)
> Well the web UI installer is working at least.
> 
> I get the feeling the Selenium might be failing due to timeouts. At least on
> my machine...

Maybe not. Increased the max_retries and didn't make a difference to t/db_dependent/selenium/01-installation.t failing.

t/db_dependent/selenium/00-onboarding.t still sometimes works and sometimes doesn't but mostly works...
Comment 25 David Cook 2024-02-21 00:10:25 UTC
This is so frustrating. I add $s->driver->get_page_source() to debug t/db_dependent/selenium/01-installation.t and then that's the time where it succeeds. 

But then t/db_dependent/selenium/administration_tasks.t is failing with an error like the following:

Error while executing command: no such element: Unable to locate element: //*[@id="login_password"] at /usr/share/perl5/Selenium/Remote/Driver.pm line 411.
Comment 26 David Cook 2024-02-21 00:23:30 UTC
It looks like e68cfc408da984f9bcf0ee0011ff7fea49758d0d "Bug 36102: (follow-up) Add cud-login to the login form" has accidentally broken a bunch of the Selenium tests. 

It looks like that's why some are consistently failing, but the web UI is working. 

"fill_form" in t/lib/Selenium.pm tries to look up parameter keys as "id" attributes of HTML elements and login_userid and login_password aren't "id" values; they're only "name" values. So they're causing Selenium errors because the elements can't be retrieved. 

Let me know if I haven't expressed myself clearly enough here. Basically this was the breaking change:

-    $self->fill_form( { userid => $login, password => $password } );
+    $self->fill_form( { login_userid => $login, login_password => $password } );

It doesn't explain why 00-onboarding.t and 01-installation.t sporadically fail, but I assume those are related to race conditions since they sometimes pass and sometimes fail. I could be wrong for those though...

--

With that figured it out, I'm going to see about adding my Koha::Token change to bug34478... and then probably come back here to apply it too to see if it has any negative impact.
Comment 27 David Cook 2024-02-21 00:27:40 UTC
(In reply to Jonathan Druart from comment #20)
> (In reply to Jonathan Druart from comment #19)
> > Additional there is a regression: at the end of the installer you are always
> > getting "invalid csrf token" (not displayed on the UI, it says "session
> > expired"). You need to login twice.
> 
> Fixed with "Bug 36102: If CSRF check fails, try with anonymous" which feels
> quite ugly, but... why not?

This should be unnecessary following my Koha::Token change, but we'll see in a couple of minutes...
Comment 28 David Cook 2024-02-21 01:11:36 UTC
(In reply to David Cook from comment #27)
> (In reply to Jonathan Druart from comment #20)
> > (In reply to Jonathan Druart from comment #19)
> > > Additional there is a regression: at the end of the installer you are always
> > > getting "invalid csrf token" (not displayed on the UI, it says "session
> > > expired"). You need to login twice.
> > 
> > Fixed with "Bug 36102: If CSRF check fails, try with anonymous" which feels
> > quite ugly, but... why not?
> 
> This should be unnecessary following my Koha::Token change, but we'll see in
> a couple of minutes...

I realize that they're in separate functions and while "Bug 36102: If CSRF check fails, try with anonymous" shouldn't be necessary, it doesn't cause any harm.
Comment 29 David Cook 2024-02-21 01:18:22 UTC
(In reply to Jonathan Druart from comment #19)
> Two new commits added to the remote branch
> 
> Bug 36102: (follow-up) Add cud-login to the login form
> Bug 36102: Do not keep op and csrf_token in param list after login - OPAC
> Bug 36102: Generate a new sessionID if the existing one is invalid
> Bug 36102: Remove cookie from the installer session
> 
> They need extensive review.

"Bug 36102: (follow-up) Add cud-login to the login form"

Breaks Selenium tests as I noted in my previous comment due to how t::lib::Selenium::fill_form() works.

However, it looks like a reasonable change overall. Perhaps we update the IDs for all the form controls to match the new login_ prefixes. That fixes the Selenium issue and makes things more consistent. 

Jonathan, would you agree with that?
Comment 30 David Cook 2024-02-21 01:37:08 UTC
(In reply to Jonathan Druart from comment #19)
> Bug 36102: Do not keep op and csrf_token in param list after login - OPAC

Looks reasonable, although I'm not familiar with this code flow.

> Bug 36102: Generate a new sessionID if the existing one is invalid

I don't know that this tests for an invalid sessionID so much as a missing sessionID, which should be impossible because higher up in the code is this line:

$sessionID = $session->id;

So I don't know about this one... but I don't think it can cause any harm. 

> Bug 36102: Remove cookie from the installer session

I'm curious about this one. It looks like it only affects upgrades and not fresh installs.

On a fresh install, we go from onboarding.pl to mainpage.pl and I see that we request mainpage.pl using the CGISESSID we used for the Installer and mainpage.pl replies with a new session value in its response CGISESSID.

Just tested on an upgrade and it's throwing a fatal error. I'll investigate...
Comment 31 David Cook 2024-02-21 01:49:10 UTC
(In reply to David Cook from comment #30)
> > Bug 36102: Remove cookie from the installer session
> 
> I'm curious about this one. It looks like it only affects upgrades and not
> fresh installs.
> 
> On a fresh install, we go from onboarding.pl to mainpage.pl and I see that
> we request mainpage.pl using the CGISESSID we used for the Installer and
> mainpage.pl replies with a new session value in its response CGISESSID.
> 
> Just tested on an upgrade and it's throwing a fatal error. I'll
> investigate...

I'm not 100% sure this one was necessary, but I've gone ahead and fixed it. Looks like the Installer isn't CookieManager aware so just needs some extra care using it there.
Comment 32 David Cook 2024-02-21 01:50:09 UTC
(In reply to David Cook from comment #31)
> I'm not 100% sure this one was necessary, but I've gone ahead and fixed it.
> Looks like the Installer isn't CookieManager aware so just needs some extra
> care using it there.

My change is quick and dirty.. probably better to add support for Koha::CookieManager more fully to the Installer but I figure we have a different topic on our minds at the moment...
Comment 33 Jonathan Druart 2024-02-21 07:34:15 UTC
(In reply to David Cook from comment #26)
> It looks like e68cfc408da984f9bcf0ee0011ff7fea49758d0d "Bug 36102:
> (follow-up) Add cud-login to the login form" has accidentally broken a bunch
> of the Selenium tests. 
> 
> It looks like that's why some are consistently failing, but the web UI is
> working. 
> 
> "fill_form" in t/lib/Selenium.pm tries to look up parameter keys as "id"
> attributes of HTML elements and login_userid and login_password aren't "id"
> values; they're only "name" values. So they're causing Selenium errors
> because the elements can't be retrieved. 
> 
> Let me know if I haven't expressed myself clearly enough here. Basically
> this was the breaking change:
> 
> -    $self->fill_form( { userid => $login, password => $password } );
> +    $self->fill_form( { login_userid => $login, login_password => $password
> } );

Oops yes, I thought I had reverted those changes. Adjusting now (amending the commit).

(In reply to David Cook from comment #29)
> (In reply to Jonathan Druart from comment #19)
> > Two new commits added to the remote branch
> > 
> > Bug 36102: (follow-up) Add cud-login to the login form
> > Bug 36102: Do not keep op and csrf_token in param list after login - OPAC
> > Bug 36102: Generate a new sessionID if the existing one is invalid
> > Bug 36102: Remove cookie from the installer session
> > 
> > They need extensive review.
> 
> "Bug 36102: (follow-up) Add cud-login to the login form"
> 
> Breaks Selenium tests as I noted in my previous comment due to how
> t::lib::Selenium::fill_form() works.
> 
> However, it looks like a reasonable change overall. Perhaps we update the
> IDs for all the form controls to match the new login_ prefixes. That fixes
> the Selenium issue and makes things more consistent. 
> 
> Jonathan, would you agree with that?

Nope. It will be more consistent, but more error prone as well. That's a lot more changes.
Comment 34 Jonathan Druart 2024-02-21 09:34:32 UTC
David, "Bug 34478: Manual fix - Make Koha::Token use session id not userenv id" is fixing 01-instalation.t, but I think there is still something hidden behind it.

The token is generated using "koha_kohadev", then we are checking with "anonymous" (twice then, that's silly but well...)
It seems that we are not setting the userenv properly somewhere.
There is something that bothers me (see also comment 8), we are relying on userenv being set when CGI->new is called but that feels hazardous. I don't even understand how it is working now: we are calling set_userenv in checkauth, which is always called after CGI->new.
Comment 35 Jonathan Druart 2024-02-21 09:44:39 UTC
(In reply to Jonathan Druart from comment #34)
> David, "Bug 34478: Manual fix - Make Koha::Token use session id not userenv
> id" is fixing 01-instalation.t, but I think there is still something hidden
> behind it.
> 
> The token is generated using "koha_kohadev", then we are checking with
> "anonymous" (twice then, that's silly but well...)
> It seems that we are not setting the userenv properly somewhere.
> There is something that bothers me (see also comment 8), we are relying on
> userenv being set when CGI->new is called but that feels hazardous. I don't
> even understand how it is working now: we are calling set_userenv in
> checkauth, which is always called after CGI->new.

See Bug 34478 comment 153.
Comment 36 Kyle M Hall 2024-02-21 15:51:32 UTC
(In reply to Jonathan Druart from comment #34)
> David, "Bug 34478: Manual fix - Make Koha::Token use session id not userenv
> id" is fixing 01-instalation.t, but I think there is still something hidden
> behind it.
> 
> The token is generated using "koha_kohadev", then we are checking with
> "anonymous" (twice then, that's silly but well...)
> It seems that we are not setting the userenv properly somewhere.
> There is something that bothers me (see also comment 8), we are relying on
> userenv being set when CGI->new is called but that feels hazardous. I don't
> even understand how it is working now: we are calling set_userenv in
> checkauth, which is always called after CGI->new.

I'm not sure I understand what you mean. We get the sessionid from the browser cookie via CGI, so as long as CGI->new is called before checkauth/set_userenv everything should always work. Right? Am I making a mistake in my logic?
Comment 37 David Cook 2024-02-22 05:36:54 UTC
(In reply to Kyle M Hall from comment #36)
> (In reply to Jonathan Druart from comment #34)
> > David, "Bug 34478: Manual fix - Make Koha::Token use session id not userenv
> > id" is fixing 01-instalation.t, but I think there is still something hidden
> > behind it.
> > 
> > The token is generated using "koha_kohadev", then we are checking with
> > "anonymous" (twice then, that's silly but well...)
> > It seems that we are not setting the userenv properly somewhere.
> > There is something that bothers me (see also comment 8), we are relying on
> > userenv being set when CGI->new is called but that feels hazardous. I don't
> > even understand how it is working now: we are calling set_userenv in
> > checkauth, which is always called after CGI->new.
> 
> I'm not sure I understand what you mean. We get the sessionid from the
> browser cookie via CGI, so as long as CGI->new is called before
> checkauth/set_userenv everything should always work. Right? Am I making a
> mistake in my logic?

So "Bug 34778: Manual fix - Make Koha::Token use session id not userenv id" should make it so that the sessionID and the "userid" of the user as recorded in the database session with sessionID is used both for generating and checking the CSRF token.

So it should be all good now following my fix. Shouldn't need to worry about userenv anymore in this regard.
Comment 38 Jonathan Druart 2024-02-22 05:56:20 UTC
Yes sorry Kyle, the comment was confusing.

What I was describing is the behaviour *without* "Make Koha::Token use session id not userenv id".
Comment 39 Kyle M Hall 2024-02-22 14:39:18 UTC
(In reply to Jonathan Druart from comment #38)
> Yes sorry Kyle, the comment was confusing.
> 
> What I was describing is the behaviour *without* "Make Koha::Token use
> session id not userenv id".

Ah, thanks yinz! That's a relief!
Comment 40 Jonathan Druart 2024-03-01 13:21:28 UTC
Pushed to master for 24.05.00.
Comment 41 Fridolin Somers 2024-04-17 08:49:30 UTC
Depends on Bug 34478 not in 23.11.x