[Bug 37060] New: KOCT cannot send circulation data due to missing csrf token
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Bug ID: 37060 Summary: KOCT cannot send circulation data due to missing csrf token Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs@lists.koha-community.org Reporter: bibliothek@th-wildau.de QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, kyle.m.hall@gmail.com Just tried using the firefox offline circulation tool (koct) and ran into these console errors: ==> /var/log/koha/kohadev/plack-intranet-error.log <== [2024/06/10 11:55:12] [WARN] Programming error - No CSRF token passed for POST http://localhost:8081/intranet/offline_circ/service.pl (referer: No referer) at /kohadevbox/koha/Koha/Middleware/CSRF.pm line 82. To reproduce: a) install firefox addon linked in http://localhost:8081/cgi-bin/koha/circ/circulation-home.pl b) in the plugin settings: server: http://localhost:8081 Login: koha Password: koha c) test login d) check logs for [WARN] Programming error - No CSRF token passed for POST http://localhost:8081/intranet/offline_circ/service.pl (referer: No referer) at /kohadevbox/koha/Koha/Middleware/CSRF.pm line 82. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Jan Kissig <bibliothek@th-wildau.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Looks like BibLibre might maintain that tool? Looks like Bywater will need to update their desktop app too. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- Note that a short-term solution might be for them to use the SVC API. (I don't include links anymore as Bugzilla always autobans me when I do, but you can find out more on the wiki for page "Koha /svc/ HTTP API") -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|KOCT cannot send |KOCT cannot send |circulation data due to |circulation data due to |missing csrf token |missing CSRF token -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |claire.hernandez@biblibre.c | |om, | |fridolin.somers@biblibre.co | |m, | |matthias.meusburger@biblibr | |e.com, | |paul.poulain@biblibre.com --- Comment #3 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Adding Claire, Matts and Frido to the bug, as they are listed here: https://addons.mozilla.org/de/firefox/addon/koct/ And Kyle for the desktop application. I believe the KOCT plugin is still used in a lot of libraries, I know ours do. I am not sure the svc is a great option, do we have others? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #4 from Jan Kissig <bibliothek@th-wildau.de> --- With Bug 24401 (checkin endpoint) and Bug 37253 (checkout via barcode) it would be possible to use the API for KOCT. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Amanda Campbell <acampbell@hmcpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |acampbell@hmcpl.org -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert@arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- So I'm not 100% sure what I meant by my earlier comments. But what I should've meant was that the author of the Firefox add-on could use the SVC API to obtain a CSRF token and then do its existing POST. Happy to collaborate with BibLibre on this one, if they want any clarification on what I mean here. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lisette@bywatersolutions.co | |m -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #6 from Matthias Meusburger <matthias.meusburger@biblibre.com> --- Thanks David for the feedback! You're thinking about https://wiki.koha-community.org/wiki/Koha_/svc/_HTTP_API#Changes_coming_in_K... ? "This initial request generates a CGISESSID cookie linked to an anonymous session and provides a Csrf-Token in a response header." Correct? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- (In reply to Matthias Meusburger from comment #6)
Thanks David for the feedback!
You're thinking about https://wiki.koha-community.org/wiki/Koha_/svc/ _HTTP_API#Changes_coming_in_Koha_24.05 ?
"This initial request generates a CGISESSID cookie linked to an anonymous session and provides a Csrf-Token in a response header."
Correct?
More or less! Basically, you do that first anonymous GET request to get the anonymous CGISESSID cookie and a Csrf-Token (via the HTTP response headers): e.g. curl -v 'http://localhost:8081/cgi-bin/koha/svc/authentication' --cookie-jar /tmp/test.cookies Then, using that same cookie and that Csrf-Token, you'll probably want to login using that endpoint as well (I'll explain more in a moment): e.g. curl -v -H "Content-Type: application/x-www-form-urlencoded" -H "Csrf-Token: 4dda36756ec4f7ac178fb5500e1873b6f50cf9bc,699bc3e9fbb01ca7282bc8d847d8a018e696d327,1716342462" -XPOST -v 'http://localhost:8081/cgi-bin/koha/svc/authentication' -d "login_userid=koha&login_password=koha" --cookie /tmp/test.cookies --cookie-jar /tmp/test.cookies Now the reason you'll probably want to do this is because you'll get a *NEW* authenticated CGISESSID cookie, and a *NEW* CSRF token. You can use these *NEW* credentials for as long as the cookie and token are valid (the token is valid for up to 8 hours if I recall correctly). If you skip this step, you'll probably get stuck, since "offline/service.pl" doesn't appear to return a cookie or Csrf-Token. In other words, if you skip this login step, you'd have to repeat the 1st step for every "offline_circ/service.pl" request, and you don't want to do that. Anyway, then, you should be able to do as many API requests as you want to that "offline_circ/service.pl" script. -- Let me know if that doesn't make sense. You can look at "./misc/migration_tools/koha-svc.pl" for some examples of what this looks like in practice. If you have a public git for it, I could also take a little look to make more in-context comments. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #8 from David Cook <dcook@prosentient.com.au> --- Matts, can we marked this one as assigned to you? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Matthias Meusburger <matthias.meusburger@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |matthias.meusburger@biblibr |ity.org |e.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #9 from Matthias Meusburger <matthias.meusburger@biblibre.com> --- I've assigned this ticket to myself, yes. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Todd Goatley <tgoatley@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tgoatley@gmail.com --- Comment #10 from Todd Goatley <tgoatley@gmail.com> --- HI Matthias! Apologies, I'm sure you're busy and we're in the holiday season but there have been libraries requesting information on the status of this bug. Any update/timeline would be greatly appreciated. Thank you, sir! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #11 from Matthias Meusburger <matthias.meusburger@biblibre.com> --- Hi! So, the current status is: I already gave it a shot a few weeks back, but didn't succeed at implement David's solution (which works perfectly well using command line) in KOCT. So I definitely have to have another look at it. If anyone has a working fix, we accept pull requests here: https://git.biblibre.com/biblibre/koct-webext And, I know it is not ideal, but in the meantime, users can still export data (.koc file) from KOCT and upload it in the offline circulation tool in Koha. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- (In reply to Matthias Meusburger from comment #11)
So, the current status is: I already gave it a shot a few weeks back, but didn't succeed at implement David's solution (which works perfectly well using command line) in KOCT.
Are you using LWP::UserAgent? If so, double-check if you're setting a cookie_jar. From memory, LWP::UserAgent doesn't retain cookies in between requests, so you'll need to remember to set "cookie_jar" to {} either in the constructor or using a method after object creation. Just guessing that might be the gotcha. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #13 from David Cook <dcook@prosentient.com.au> --- (In reply to Matthias Meusburger from comment #11)
So, the current status is: I already gave it a shot a few weeks back, but didn't succeed at implement David's solution (which works perfectly well using command line) in KOCT.
If anyone has a working fix, we accept pull requests here: https://git.biblibre.com/biblibre/koct-webext
Ah, I forgot it was a browser extension and not a Perl script. That's extra interesting... I'd have to see your patches, but 1 problem would be that "userid" and "password" have become "login_userid" and "login_password" in Koha, so the current koct.js won't authenticate correctly anyway. -- But yeah looking through the koct.js code and offline_circ/service.pl... the Koha session cookie is probably where the problem is. It's been a long time since I wrote a browser extension, so I don't recall the intricacies of CORS requests in them. Might need to set 'xhr.withCredentials = true' to get the cookie response for the SVC API stuff. -- Alas, I won't have time to look at this for a month at least :/. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #14 from Jan Kissig <bibliothek@th-wildau.de> --- Hi there, I tried to implement what David said but somehow the authenticated cookie and the CRSF-token are bound together, and when I loose that token (but keep the session), there seems no chance of getting a valid token again. Wiki says: If you lose it for whatever reason, you can get a new Csrf-Token by using your authenticated cookie and sending a GET to /cgi-bin/koha/svc/authentication like you did in the first step. --- The token I received by GET /cgi-bin/koha/svc/authentication will always throw "wrong_csrf_token" so I build a workaround by logging out if GET /cgi-bin/koha/svc/authentication returns a valid session (<status>ok</status>) I uploaded a fixed version to https://gitlab.com/bibliothekTHWildau/koct-webext as I don't know if a pull request would work as I have no account on your git server. If someone wants to try with firefox (I used a german firefox , so maybe the naming is a bit different): - go to addons and themes - click the cog wheel and debug addons - load temporary add on - navigate to the downloaded extension and double click manifest.json -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #15 from David Cook <dcook@prosentient.com.au> --- (In reply to Jan Kissig from comment #14)
Hi there, I tried to implement what David said but somehow the authenticated cookie and the CRSF-token are bound together, and when I loose that token (but keep the session), there seems no chance of getting a valid token again.
So the cookie contains the session ID, and the CSRF token is bound to that session ID.
Wiki says: If you lose it for whatever reason, you can get a new Csrf-Token by using your authenticated cookie and sending a GET to /cgi-bin/koha/svc/authentication like you did in the first step. ---
The token I received by GET /cgi-bin/koha/svc/authentication will always throw "wrong_csrf_token" so I build a workaround by logging out if GET /cgi-bin/koha/svc/authentication returns a valid session (<status>ok</status>)
I've just confirmed your problem using curl, so I'll look into that. Something very odd going on here, especially since I'm sure this used to work... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #16 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #15)
I've just confirmed your problem using curl, so I'll look into that. Something very odd going on here, especially since I'm sure this used to work...
So it looks like a bug in C4::Auth::check_api_auth, but it looks like a bug that has existed for years, so maybe this only worked theoretically in the past... Basically, C4::Auth::check_api_auth() sometimes returns $sessionID and sometimes it returns $session (like in the case where you already have an authenticated cookie), even though it's supposed to always return $sessionID. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38826 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #17 from David Cook <dcook@prosentient.com.au> --- I've posted a patch to bug 38826, but yeah... I'd say have to use a workaround in the meantime. Btw, I think instead of hitting '/cgi-bin/koha/mainpage.pl?logout.x=1' you could use "credentials: 'omit'" to force a new login, but I suppose it's all the same in the end. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #18 from Todd Goatley <tgoatley@gmail.com> --- (In reply to David Cook from comment #17)
I've posted a patch to bug 38826, but yeah... I'd say have to use a workaround in the meantime.
Btw, I think instead of hitting '/cgi-bin/koha/mainpage.pl?logout.x=1' you could use "credentials: 'omit'" to force a new login, but I suppose it's all the same in the end.
Thank you David and Matthias! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #19 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to David Cook from comment #17)
I've posted a patch to bug 38826, but yeah... I'd say have to use a workaround in the meantime.
Btw, I think instead of hitting '/cgi-bin/koha/mainpage.pl?logout.x=1' you could use "credentials: 'omit'" to force a new login, but I suppose it's all the same in the end.
Hi David, thx for filing 38826. This changed the token handling a lot, as no logout is necessary anymore. I fixed the web extension based on bug_38826 and uploaded a new version (see #14) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #20 from David Cook <dcook@prosentient.com.au> --- (In reply to Todd Goatley from comment #18)
Thank you David and Matthias!
Thank you Jan too :D (In reply to Jan Kissig from comment #19)
thx for filing 38826. This changed the token handling a lot, as no logout is necessary anymore. I fixed the web extension based on bug_38826 and uploaded a new version (see #14)
Thanks for testing 38826. Hopefully we can get the patch into Koha soon. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #21 from David Cook <dcook@prosentient.com.au> --- Bug 38826 has been pushed for 25.05.00. I'm asking for it to be backported to 24.11 and 24.05 as well, since those are the other versions that use anti-CSRF tokens. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #22 from Matthias Meusburger <matthias.meusburger@biblibre.com> --- Thanks Jan for your patches. I have tested them successfully and will update KOCT on addons.mozilla.org as soon as possible. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #23 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to Matthias Meusburger from comment #22)
Thanks Jan for your patches.
I have tested them successfully and will update KOCT on addons.mozilla.org as soon as possible.
Hey Matthias, I did test it for 24.05 and main but I think it will not work with older, but still used, koha versions. As add-ons can automatically be updated this would break things for older kohas. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #24 from Matthias Meusburger <matthias.meusburger@biblibre.com> --- You're right. We need a patch that detects the Koha version and adapt KOCT behavior accordingly, or a configuration option to set Koha version if we cannot detect it automatically. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Pirkko-Liisa Lauhikari <pirkko-liisa.lauhikari@ouka.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pirkko-liisa.lauhikari@ouka | |.fi -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #25 from Matthias Meusburger <matthias.meusburger@biblibre.com> --- Hi, I've added a github repository for KOCT to make future contributions easier: https://github.com/biblibre/firefox-addon-koct I've also added a patch that allows the user to choose Koha's version in the options in order to adapt koct's behavior (ie: with or without csrf). I've tested it successfully on pre-24.05 and main. It should work with all versions once Bug 38826 is backported to 24.11 and 24.05. Could someone test this before I make a new release of the plugin? Thanks. (The plugin can be tested by following the steps described on comment 14: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060#c14 ) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|rcoert@arlingtonva.us | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Rebecca Coert <rcoert@arlingtonva.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcoert@arlingtonva.us -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Eric Bégin <eric.begin@inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eric.begin@inLibro.com --- Comment #26 from Eric Bégin <eric.begin@inLibro.com> --- No more Missing CSRF token error ! However, the "Send data to Koha" commit option seems broken. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #27 from Eric Bégin <eric.begin@inLibro.com> --- It works! My problem was that I was not connected on the right branch. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #28 from Matthias Meusburger <matthias.meusburger@biblibre.com> --- Thanks Éric for testing, thanks everyone involved in this BZ. The new 4.0.21 version of the KOCT firefox add-on has been submitted to addons.mozilla.org and is waiting for approval. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #29 from Matthias Meusburger <matthias.meusburger@biblibre.com> --- Version 4.0.21 has been approved and is now available at https://addons.mozilla.org/fr/firefox/addon/koct/ -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Kyle M Hall (khall) <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com --- Comment #30 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- (In reply to Matthias Meusburger from comment #29)
Version 4.0.21 has been approved and is now available at https://addons.mozilla.org/fr/firefox/addon/koct/
We have a partner running Koha 24.05. When we try to configure the plugin we get the "Forbidden" message. I've selected Koha version >= 24.05 in the settings. I've verified this myself with the latest plugin version ( 0.4.21 ). Any idea what's going on? Here are the logs: ==> /var/log/koha/library/plack.log <== 24.165.212.106 - - [02/Apr/2025:09:05:18 -0400] "GET /intranet_svc/authentication HTTP/1.1" 200 84 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:136.0) Gecko/20100101 Firefox/136.0" ==> /var/log/koha/library/intranet-access.log <== staff.library.bywatersolutions.com:80 24.165.212.106 - - [02/Apr/2025:09:05:18 -0400] "GET /cgi-bin/koha/svc/authentication HTTP/1.1" 200 504 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:136.0) Gecko/20100101 Firefox/136.0" ==> /var/log/koha/library/plack-intranet-error.log <== [2025/04/02 09:05:18] [WARN] wrong_csrf_token at /usr/share/koha/lib/Koha/Middleware/CSRF.pm line 97. ==> /var/log/koha/library/plack.log <== 24.165.212.106 - - [02/Apr/2025:09:05:18 -0400] "POST /intranet_svc/authentication HTTP/1.1" 403 16 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:136.0) Gecko/20100101 Firefox/136.0" ==> /var/log/koha/library/intranet-access.log <== staff.library.bywatersolutions.com:80 24.165.212.106 - - [02/Apr/2025:09:05:18 -0400] "POST /cgi-bin/koha/svc/authentication HTTP/1.1" 403 197 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:136.0) Gecko/20100101 Firefox/136.0" -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #31 from Matthias Meusburger <matthias.meusburger@biblibre.com> --- Hi Kyle! I'm not sure why you have this error, but I just tested on a fresh 24.05.08 koha, with koct 0.4.21 and it worked. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #32 from Kyle M Hall (khall) <kyle@bywatersolutions.com> --- (In reply to Matthias Meusburger from comment #31)
Hi Kyle!
I'm not sure why you have this error, but I just tested on a fresh 24.05.08 koha, with koct 0.4.21 and it worked.
Thanks for checking! I'll have to dig deeper then! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |38826 --- Comment #33 from David Cook <dcook@prosentient.com.au> --- (In reply to Kyle M Hall (khall) from comment #32)
(In reply to Matthias Meusburger from comment #31)
Hi Kyle!
I'm not sure why you have this error, but I just tested on a fresh 24.05.08 koha, with koct 0.4.21 and it worked.
Thanks for checking! I'll have to dig deeper then!
I think that you'll want to double-check the Koha version. Not sure why I listed bug 38826 as "See Also" rather than as a dependency. I'll fix that... Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38826 [Bug 38826] C4::Auth::check_api_auth sometimes returns $session and sometimes returns $sessionID -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #34 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I see the Forbidden message on our Koha 24.11.04 test installation. An older 22.11.23 seems to work OK. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #35 from Jan Kissig <bibliothek@th-wildau.de> --- Just tested on production 24.05.7 -> forbidden. Updated to 24.05.08-1 -> it works. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #36 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Jan Kissig from comment #35)
Just tested on production 24.05.7 -> forbidden. Updated to 24.05.08-1 -> it works.
I still see this forbidden with Koha version 24.11.02 when I try to test the configuration. It worked briefly then stopped, also get a forbidden when trying to upload transactions. Any ideas? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #37 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to Katrin Fischer from comment #36)
(In reply to Jan Kissig from comment #35)
Just tested on production 24.05.7 -> forbidden. Updated to 24.05.08-1 -> it works.
I still see this forbidden with Koha version 24.11.02 when I try to test the configuration. It worked briefly then stopped, also get a forbidden when trying to upload transactions.
Any ideas?
Just checked with 24.11.04.000 and 24.05.09 and it worked in both environments. As David mentioned in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060#c33 it is depending on bug 38826 which is not pushed on 24.11.02. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Bug 37060 depends on bug 38826, which changed state. Bug 38826 Summary: C4::Auth::check_api_auth sometimes returns $session and sometimes returns $sessionID https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38826 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to oldoldoldstable |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion --- Comment #38 from David Cook <dcook@prosentient.com.au> --- What's the status of this one? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Matthias Meusburger <matthias.meusburger@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |38327 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38327 [Bug 38327] 403 errors when logging back into Koha after timeout -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #39 from Matthias Meusburger <matthias.meusburger@biblibre.com> --- Hi, I ran into the same wrong_csrf_token issue, which was fixed by closing and re-opening the browser. I have a feeling that this is linked to Bug 38327, but this has to be investigated. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 Jan Kissig <bibliothek@th-wildau.de> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://github.com/biblibre | |/firefox-addon-koct -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #40 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to Matthias Meusburger from comment #39)
Hi,
I ran into the same wrong_csrf_token issue, which was fixed by closing and re-opening the browser.
I have a feeling that this is linked to Bug 38327, but this has to be investigated.
Hi Matthias, did you mean you ran into the wrong_csrf_token issue when using koct? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #41 from Matthias Meusburger <matthias.meusburger@biblibre.com> ---
Hi Matthias, did you mean you ran into the wrong_csrf_token issue when using koct?
Hi, yes, this is what I meant. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #42 from David Cook <dcook@prosentient.com.au> --- (In reply to Matthias Meusburger from comment #39)
Hi,
I ran into the same wrong_csrf_token issue, which was fixed by closing and re-opening the browser.
I have a feeling that this is linked to Bug 38327, but this has to be investigated.
It would depend on how long you hold on to the session cookie and CSRF token I suppose. Are you doing authenticating for each interaction KOCT has with Koha or only sometimes? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #43 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to David Cook from comment #42)
(In reply to Matthias Meusburger from comment #39)
Hi,
I ran into the same wrong_csrf_token issue, which was fixed by closing and re-opening the browser.
I have a feeling that this is linked to Bug 38327, but this has to be investigated.
It would depend on how long you hold on to the session cookie and CSRF token I suppose. Are you doing authenticating for each interaction KOCT has with Koha or only sometimes?
Every time before committing the circulation data to Koha, KOCT sends a GET /cgi-bin/koha/svc/authentication and retrieves SESSIONID and CSRF-Token from that response. If the response is like <status>ok the circulation data is POSTed to /cgi-bin/koha/offline_circ/service.pl. If the response is like <status>expired a POST /cgi-bin/koha/svc/authentication is made. So KOCT checks the auth status every time before sendign data to Koha but will re-auth when a session is expired. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #44 from David Cook <dcook@prosentient.com.au> --- (In reply to Jan Kissig from comment #43)
Every time before committing the circulation data to Koha, KOCT sends a
GET /cgi-bin/koha/svc/authentication
and retrieves SESSIONID and CSRF-Token from that response. If the response is like
<status>ok
the circulation data is POSTed to /cgi-bin/koha/offline_circ/service.pl.
If the response is like
<status>expired
a POST /cgi-bin/koha/svc/authentication is made.
So KOCT checks the auth status every time before sendign data to Koha but will re-auth when a session is expired.
That sounds slightly problematic. Before doing "POST /cgi-bin/koha/svc/authentication" I think a new "GET /cgi-bin/koha/svc/authentication" will be needed to get a new session, because the old one will have been deleted so the CSRF token for that POST won't work. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #45 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to David Cook from comment #44)
(In reply to Jan Kissig from comment #43)
Every time before committing the circulation data to Koha, KOCT sends a
GET /cgi-bin/koha/svc/authentication
and retrieves SESSIONID and CSRF-Token from that response. If the response is like
<status>ok
the circulation data is POSTed to /cgi-bin/koha/offline_circ/service.pl.
If the response is like
<status>expired
a POST /cgi-bin/koha/svc/authentication is made.
So KOCT checks the auth status every time before sendign data to Koha but will re-auth when a session is expired.
That sounds slightly problematic. Before doing "POST /cgi-bin/koha/svc/authentication" I think a new "GET /cgi-bin/koha/svc/authentication" will be needed to get a new session, because the old one will have been deleted so the CSRF token for that POST won't work.
you mean a second GET /cgi-bin/koha/svc/authentication when the first GET /cgi-bin/koha/svc/authentication returns an 'expired'? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #46 from David Cook <dcook@prosentient.com.au> --- (In reply to Jan Kissig from comment #45)
(In reply to David Cook from comment #44)
(In reply to Jan Kissig from comment #43)
Every time before committing the circulation data to Koha, KOCT sends a
GET /cgi-bin/koha/svc/authentication
and retrieves SESSIONID and CSRF-Token from that response. If the response is like
<status>ok
the circulation data is POSTed to /cgi-bin/koha/offline_circ/service.pl.
If the response is like
<status>expired
a POST /cgi-bin/koha/svc/authentication is made.
So KOCT checks the auth status every time before sendign data to Koha but will re-auth when a session is expired.
That sounds slightly problematic. Before doing "POST /cgi-bin/koha/svc/authentication" I think a new "GET /cgi-bin/koha/svc/authentication" will be needed to get a new session, because the old one will have been deleted so the CSRF token for that POST won't work.
you mean a second GET /cgi-bin/koha/svc/authentication when the first GET /cgi-bin/koha/svc/authentication returns an 'expired'?
I think I misunderstood what you said before. I thought you said the "expired" was coming from the POST to /cgi-bin/koha/offline_circ/service.pl I don't know why GET /cgi-bin/koha/svc/authentication would return "expired" unless a cookie jar was being re-used from a previous interaction. I would think the first GET /cgi-bin/koha/svc/authentication would be <status>failed and then you'd use the Csrf-Token and cookie from there -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #47 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to David Cook from comment #46)
(In reply to Jan Kissig from comment #45)
(In reply to David Cook from comment #44)
(In reply to Jan Kissig from comment #43)
Every time before committing the circulation data to Koha, KOCT sends a
GET /cgi-bin/koha/svc/authentication
and retrieves SESSIONID and CSRF-Token from that response. If the response is like
<status>ok
the circulation data is POSTed to /cgi-bin/koha/offline_circ/service.pl.
If the response is like
<status>expired
a POST /cgi-bin/koha/svc/authentication is made.
So KOCT checks the auth status every time before sendign data to Koha but will re-auth when a session is expired.
That sounds slightly problematic. Before doing "POST /cgi-bin/koha/svc/authentication" I think a new "GET /cgi-bin/koha/svc/authentication" will be needed to get a new session, because the old one will have been deleted so the CSRF token for that POST won't work.
you mean a second GET /cgi-bin/koha/svc/authentication when the first GET /cgi-bin/koha/svc/authentication returns an 'expired'?
I think I misunderstood what you said before. I thought you said the "expired" was coming from the POST to /cgi-bin/koha/offline_circ/service.pl
I don't know why GET /cgi-bin/koha/svc/authentication would return "expired" unless a cookie jar was being re-used from a previous interaction.
I would think the first GET /cgi-bin/koha/svc/authentication would be <status>failed and then you'd use the Csrf-Token and cookie from there
If KOCT is used in the same browser window as Koha, KOCT will use the cookie (and therefore the session) of the logged in Koha user. This alone can be confusing as when running the settings of KOCT a new login is performed and therefore the existing Koha session gets overwritten with the session of the KOCT user. GET /cgi-bin/koha/svc/authentication will only return failed when no cookie is set, otherwise it returns 'expired' or 'ok'. This does not explain why sudden 403s appear. I only managed to get 403s when cookies were forbidden at all and the POST was only carrying the token (not the cookie) I will analyze this a bit more, but is it possible not to have a session when using the /cgi-bin/koha/svc/authentication endpoint? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #48 from David Cook <dcook@prosentient.com.au> --- (In reply to Jan Kissig from comment #47)
If KOCT is used in the same browser window as Koha, KOCT will use the cookie (and therefore the session) of the logged in Koha user. This alone can be confusing as when running the settings of KOCT a new login is performed and therefore the existing Koha session gets overwritten with the session of the KOCT user.
Could you explain this one a bit more? I haven't used KOCT before so I don't know much about it. What's the KOCT user? Overall, it sounds like using the REST API would be better than using offline_circ/service.pl although that would just delay resolving the cookie auth issue. This reminds me of a different bug where someone talked about having the cookie path be more specific than /. Hmm food for thought...
GET /cgi-bin/koha/svc/authentication will only return failed when no cookie is set, otherwise it returns 'expired' or 'ok'.
This does not explain why sudden 403s appear. I only managed to get 403s when cookies were forbidden at all and the POST was only carrying the token (not the cookie)
No cookie? I wonder how it had a token but no cookie... What do you mean by "when cookies were forbidden at all"?
I will analyze this a bit more, but is it possible not to have a session when using the /cgi-bin/koha/svc/authentication endpoint?
Only for GETs. POSTs have to have a session and a CSRF token. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37060 --- Comment #49 from Jan Kissig <bibliothek@th-wildau.de> --- (In reply to David Cook from comment #48)
(In reply to Jan Kissig from comment #47)
If KOCT is used in the same browser window as Koha, KOCT will use the cookie (and therefore the session) of the logged in Koha user. This alone can be confusing as when running the settings of KOCT a new login is performed and therefore the existing Koha session gets overwritten with the session of the KOCT user.
Could you explain this one a bit more?
I haven't used KOCT before so I don't know much about it. What's the KOCT user?
KOCT takes a staff users credentials to login to Koha. You have to set them in the settings of KOCT. If you want to test (firefox only), its easy to install via https://addons.mozilla.org/en/firefox/addon/koct/ and you can watch the http requests via development tools.
Overall, it sounds like using the REST API would be better than using offline_circ/service.pl although that would just delay resolving the cookie auth issue.
This would require to have offline circulation available in the REST API which is not the case yet..
This reminds me of a different bug where someone talked about having the cookie path be more specific than /.
Hmm food for thought...
GET /cgi-bin/koha/svc/authentication will only return failed when no cookie is set, otherwise it returns 'expired' or 'ok'.
This does not explain why sudden 403s appear. I only managed to get 403s when cookies were forbidden at all and the POST was only carrying the token (not the cookie)
No cookie? I wonder how it had a token but no cookie...
What do you mean by "when cookies were forbidden at all"?
This was achieved by setting the strictest cookie setting in my Firefox, which breaks nearly every web app.
I will analyze this a bit more, but is it possible not to have a session when using the /cgi-bin/koha/svc/authentication endpoint?
Only for GETs. POSTs have to have a session and a CSRF token.
Maybe we should find out if libraries use KOCT and also have received the 'wrong CSRF-token' issue as in my test it never occurred. I will ask on mattermost -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org