September 2021 - Koha-devel - lists.koha-community.org

Listing Zebra (and Elasticsearch) indexes for end-users' benefit
by dcook＠prosentient.com.au 09 Sep '21

09 Sep '21

Hi all, As always, a new day brings a new Zebra idea. One of my librarians asked me if there was any way to get a list of Zebra indexes (particularly for Record Matching Rules), and I was all prepared to say no. when I remembered something I read the other day. It turns out you can send the query "@attr exp1 1=1 attributedetails" to the magical database "IR-explain-1", and it will give you a list of all the indexes in that database along with the type of index and how many documents are indexed against that index in the database. I think this is something that we should add to Koha! I'm not familiar with Koha's use of Elasticsearch, but I imagine there is an easy way of getting a list of Elasticsearch indexes? -- Of course, while having a list of indexes is good, it would be nice to know what MARC data is in each of those indexes. I'm thinking about creating a Koha Plugin that parses "biblio-koha-indexdefs.xml" and shows a user-friendly view of what parts of the MARC record are put into which indexes. -- What do folk think about that? I think having a list of Zebra indexes would be very useful for Record Matching Rules, but also for a "Search tips" guide for the Staff Interface and OPAC. While we could provide a static list of indexes, but I think that would be too much of a maintenance burden. I think having a list from Zebra (or Elasticsearch), which we could cache in Memcached, would be the way to go. Ideally, we could have an API route that surfaces this information, so that we could just do an AJAX lookup from a web interface. -- I'm hoping my librarian will sponsor development of a plugin, but I think this would be useful in the core Koha code. David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

3 5

Help! Plugin's API endpoint validation failing only on customer server
by Isherwood, Andrew 09 Sep '21

09 Sep '21

Hi I've been banging my head against this one for a few hours now, so I'm hoping someone can help! I've developed a Koha ILL backend for RapidILL for a customer. Part of the development was to create a plugin that provides Koha Rest API endpoints that effectively proxies to the RapidILL SOAP API. Everything works perfectly on my development server running koha-testing-docker However, on the customer's Koha instance, all API calls to the plugin fail validation with the following error: { "errors": [ { "message": "Expected object - got null.", "path": "/body" } ], "status": 400 } I'm pretty confident that my plugin and the requests I'm making to it are correct since everything works perfectly on my dev server, however the API spec is here https://github.com/PTFS-Europe/koha-plugin-rapidill/blob/main/Koha/Plugin/C… and a sample request body is: { "requestId": "17900139", "updateAction": "Cancel", "metadata": { "UpdateComment": "TEST PLEASE CANCEL REQUEST" } } The most annoying thing is that I've had this problem a few times before in the past and it's always come down to module dependency versions, though this time, I'm not sure this is the problem. I've aligned versions of the following modules on the customer's server to match the versions on my koha-testing-docker, these have been the problematic modules in the past. But still no luck: JSON - 2.90 JSON::Validator - 3.14 Mojolicious - 8.12 Mojolicious::Plugin::OpenAPI - 2.16 In an attempt to narrow it down, I've been trying to find somewhere else in Koha where a POST API call is made, but haven't found one, any idea? Does anyone have any suggestions where else I could try? Many thanks Andrew ------------------------------- Andrew Isherwood Senior Software Engineer Email: andrew.isherwood(a)ptfs-europe.com www.ptfs-europe.com Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution or copying is strictly prohibited. If you think that you have received this email message in error, please email the sender at info(a)ptfs-europe.com

2 1

Security releases for all stable branches - UPGRADE!
by Jonathan Druart 08 Sep '21

08 Sep '21

Hello everybody, Don't ignore this email! Last week a critical security bug was reported on our bug tracker. We fixed it and built debian packages for the four stable releases we currently support. The security flaw can cause a privilege escalation from OPAC users. It can be highly damaging, especially if your staff interface is accessible via login from everywhere without further security measures like IP restrictions in place. How to fix the problem? If you are using a debian-based system you should upgrade using the debian packages: % apt update % apt install koha-common If you are using an older version of Koha (<19.11) you should either upgrade to a newer version, or apply those two patches (they should apply on older versions as well): https://paste.debian.net/hidden/885fb5ec/ https://paste.debian.net/hidden/1184f523/ https://paste.debian.net/plainh/ae9f9f25 You can apply them using the following command: % wget "https://paste.debian.net/plainh/885fb5ec" -O 28929_1.patch % wget "https://paste.debian.net/plainh/1184f523" -O 28929_2.patch % wget "https://paste.debian.net/plainh/ae9f9f25" -O 28947.patch % patch -p1 -d /usr/share/koha/intranet/cgi-bin/ < /kohadevbox/koha/28929_1.patch % patch -p1 -d /usr/share/koha/opac/cgi-bin/ < /kohadevbox/koha/28929_2.patch % patch -d /usr/share/koha/opac/cgi-bin/opac/ < /kohadevbox/koha/28947.patch The two bugs are 28929 and 28947. As they contain information about how to recreate the vulnerability they will stay hidden two more days to let you upgrade your systems. Let us know if you have any questions! Regards, Jonathan

4 3

Immediate logout in Koha 21.05.02 (03?)
by Michael Kuhn 07 Sep '21

07 Sep '21

Hi As written on this list on 26 August I tried to install Koha 21.05.03 but after the installation Koha said the installed version was "21.05.02.003". Jonathan Druart wrote this comes from commit 8ea80995c590dad86c43df636456640d3aa84bab Increment version for 21.05.03 release -$VERSION = "21.05.02.002"; +$VERSION = "21.05.02.003"; Today I updated a Koha 18.11.05 database into this Koha 21.05.02.003 installation. After restarting memcached I executed "sudo koha-upgrade-schema instancename" - the output looked OK and ended with the following lines: Upgrade to 21.05.02.000 done [12:15:20]: Koha 21.05.02 release Upgrade to 21.05.02.001 done [12:15:20]: Bug 28567 - Set to NULL empty branches fields Upgrade to 21.05.02.002 done [12:15:20]: Bug 28813 - Update delivery_note to failure_code in message_queue Upgrade to 21.05.02.003 done [12:15:20]: Bug 28872 - Update syspref values from on and off to 1 and 0 It seems even if I installed Koha 21.05.03 it only upgraded to Koha 21.05.02. I don't know if there is any connection but whatever, I was able to open the staff client and to login - but as soon as I click on any link I'm logged out immediately. I am able to login again and then advance to the next link but then I'm logged out again etc ad infinitum. It is not possible to change any system preference (internal server error) or search for any users. File "plack-error.log" sometimes tells me, without a timestamp: new(): failed: query object HASH(0x555f47cfad30) does not support cookie() and param() methods: Can't call method "cookie" on unblessed reference at /usr/share/perl5/CGI/Session.pm line 707. File "plack-intranet-error.log" says: [2021/09/02 13:33:36] [WARN] Odd number of elements in anonymous hash at /usr/share/koha/intranet/cgi-bin/catalogue/search.pl line 577. Can anyone please give me a hint how to solve this problem? Best wishes: Michael -- Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz T 0041 (0)61 261 55 61 · E mik(a)adminkuhn.ch · W www.adminkuhn.ch

4 6

REST API + DataTables
by dcook＠prosentient.com.au 07 Sep '21

07 Sep '21

Thanks, Mark. That would be great! David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595 -----Original Message----- From: Koha-devel <koha-devel-bounces(a)lists.koha-community.org> On Behalf Of Mark Hofstetter Sent: Monday, 6 September 2021 9:32 PM To: koha-devel(a)lists.koha-community.org; koha-devel-request(a)lists.koha-community.org Subject: Re: [Koha-devel] Koha-devel Digest, Vol 190, Issue 4 REST API + DataTables Hi, I've written some plugins that work with datatables which seems quite straightforward to me the plugins are too specific to use widely but I would be happy to share the code anyway! regards Mark _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/

1 0

Re: [Koha-devel] Koha-devel Digest, Vol 190, Issue 4 REST API + DataTables
by Mark Hofstetter 06 Sep '21

06 Sep '21

Hi, I've written some plugins that work with datatables which seems quite straightforward to me the plugins are too specific to use widely but I would be happy to share the code anyway! regards Mark

1 0

REST API + DataTables
by dcook＠prosentient.com.au 03 Sep '21

03 Sep '21

Hi all, Do we have any examples of using the Mojolicious REST API to provide data for DataTables in Koha? I think the answer is probably no since the DataTables calls aren't really RESTful. Yet, we have this growing API, and we want to use that API to make more efficient user interfaces. Does anyone know how we might do that with DataTables? On a different project, I ended up writing a specific controller just for handling DataTables AJAX calls since they're very particular. But even that's easier said than done in a generic way because of business rules and authorization. Thoughts? David Cook Senior Software Engineer Prosentient Systems Suite 7.03 6a Glen St Milsons Point NSW 2061 Australia Office: 02 9212 0899 Online: 02 8005 0595

2 1

Fwd: Critical security bug in Koha!
by Paul Poulain 02 Sep '21

02 Sep '21

Je vous fais suivre ce mail de joubu, si qqn peut se pencher dessus et contribuer à le résoudre... (me tenir au courant svp) A+ -------- Message transféré -------- Sujet : Critical security bug in Koha! Date : Wed, 1 Sep 2021 11:34:23 +0200 De : Jonathan Druart <jonathan.druart(a)gmail.com> Pour : Martin Renvoize <martin.renvoize(a)ptfs-europe.com>, Paul Poulain <paul.poulain(a)biblibre.com>, Nick Clemens <nick(a)bywatersolutions.com>, Tomas Cohen Arazi <tomascohen(a)gmail.com>, David Cook <dcook(a)prosentient.com.au>, Philippe Blouin <philippe.blouin(a)inlibro.com>, Marcel de Rooy <M.de.Rooy(a)rijksmuseum.nl>, Andrii Vashchuk <nugged(a)gmail.com>, Katrin Fischer <Katrin.Fischer.83(a)web.de>, Chris Cormack <chris(a)bigballofwax.co.nz>, Galen Charlton <gmcharlt(a)gmail.com>, Mason James <mtj(a)kohaaloha.com>, Owen Leonard <oleonard(a)myacpl.org> Hello everybody, If you get this email I am expecting from you to talk about it to whom could be concerned. Yesterday a bug (28929) was reported about a possible privilege escalation. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28929 It is confirmed and is highlighly critical in some cases, and stay critical in all other cases. It's really bad. Basically we are missing filtering on patron's data when we create or edit a patron. Which means a user can edit whichever info they want, by modifying the DOM of the page. And, it includes borrowers.flags (that's where it hurts really badly). It impacts both OPAC and Staff interfaces. What you should do: 1. Reduce the risks! * Disable PatronSelfRegistration (!) * Disable AutoApprovePatronProfileSettings (!) or you can totally disable OPACPatronDetails 2. Make sure the staff interface is not accessible to the world 3. Remove old librarian accounts 4. Something else you have in mind? If so, please share! Then you should (or ask your team to) help us. We will need people on the bug to: 1. Write patches and discuss the best approach to fix the different issues (there are patches already) 2. Test! and test! We will have to test on five different versions (master+4 stables)! 3. QA, and *really* review, all the different versions (we really want to prevent a mess publishing a fix that will introduce regressions). We will then need to coordinate. A plan (to discuss) could be: 1. Tell the big actors to be ready for an urgent release (This is the goal of this email!) 2. Make the patches ready for the different versions (see the above) 3. Have all the packages ready, before we communicate publicly (Mason, will you be available?) 4. Tell the people we know to upgrade (so, you, and those who are aware of the problem) 5. Announce publicly What do you think? This info should not be public, but please communicate as much as you can around you (people you trust of course). No need to over communicate either, as we are not ready yet! If you don't have access to the bug, just tell me (or Tomas, Katrin, Martin, Nick, etc.) Cheers, Jonathan -- Paul Poulain, Associé-gérant / co-owner BibLibre, Services en logiciels libres pour les bibliothèques BibLibre, Open Source software and services for libraries

1 1