Looks like BibLibre might maintain that tool? 

Looks like Bywater will need to update their desktop app too.

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")

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?

With Bug 24401 (checkin endpoint) and Bug 37253 (checkout via barcode) it would be possible to use the API for KOCT.

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.

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?

(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.

Matts, can we marked this one as assigned to you?

I've assigned this ticket to myself, yes.