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

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

Perl advice for checking hash content
by Victor Grousset/tuxayo 30 Aug '21

30 Aug '21

Hi :) For a development, I'm adding additional keys to C4::Reserves::CanItemBeReserved returned hash. But there are a bunch of tests that match the whole return value and thus don't expect the new keys in the hash. Here is the best way so far I've found to adapt it. is_deeply( CanItemBeReserved( $patron->borrowernumber, $itemnumber_2 ), { status => 'tooManyReservesToday', limit => 0 }, 'Patron cannot reserve if holds_per_day is 0 (i.e. 0 is 0)' ); ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ my @status_and_limit = @{CanItemBeReserved( $patron->borrowernumber, $itemnumber_2 )}{"status", "limit"}; is_deeply( \@status_and_limit, ['tooManyReservesToday', 0], 'Patron cannot reserve if holds_per_day is 0 (i.e. 0 is 0)' ); How could this be better? Since it took me more than two hours only to have something that works and without warnings. There are surely other ways to do it™, and hopefully a nicer one. Most of the time was reading and learning by trial and error about referencing and dereferencing and the specifics or Perl hashes and array. It's odd to have been working 3.5 years on Koha closer to the code than to the librarian stuff and only have to really start learning Perl now ^^ Away, this is why advice is needed to have something that fit the good practices :) Key/Value Hash Slices would allow to not change the expected param of is_deeply() but that doesn't really look different for the readability. And isn't worth having Koha bump minimal Perl version from 5.14 (2011) to 5.20 (2014). Ok it's just for running the tests and not production but still. -> very minor or inexistent readability improvement. https://perldoc.perl.org/perldata#Key/Value-Hash-Slices Having two assertions (is() calls) for status and limit would allow a simpler syntax but add duplication. Cheers, -- Victor Grousset/tuxayo

2 2

Koha Community Newsletter: August 2021
by Koha Newsletter 27 Aug '21

27 Aug '21

The Koha Community Newsletter for August 2021 is here: * https://koha-community.org/koha-community-newsletter-august-2021/ Many thanks to everyone who submitted articles and news this newsletter! Please feel free to email me with any corrections or suggestions. -- Michael Kuhn Editor, Koha Community Newsletter

1 0

Installing Koha 21.05.03-1 but Koha gives 21.05.02.003 as the installed version
by Michael Kuhn 26 Aug '21

26 Aug '21

Hi Yesterday/today I was installing the most current Koha: $ sudo apt-cache show koha-common | grep Version Version: 21.05.03-1 During the installation of Debian package "koha-common" it says: Holen:62 http://debian.koha-community.org/koha 21.05/main amd64 koha-common all 21.05.03-1 [41,1 MB] ... Vorbereitung zum Entpacken von .../485-koha-common_21.05.03-1_all.deb ... Entpacken von koha-common (21.05.03-1) ... ... koha-common (21.05.03-1) wird eingerichtet ... But after the installation I see the following in Koha menu "About Koha": Koha version: 21.05.02.003 Also in the source text of the OPAC main page it says: <meta name="generator" content="Koha 21.0502003" /> This happened on a completely new machine with Debian GNU Linux 11.0. 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

2 1

Character sets in MariaDB 10.5
by Michael Kuhn 26 Aug '21

26 Aug '21

Hi 1. In the last few years when installing Koha on Debian GNU/Linux 9 or 10 the character sets in MariaDB were as follows: MariaDB [(none)]> SHOW VARIABLES LIKE '%char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8mb4 | | character_set_connection | utf8mb4 | | character_set_database | utf8mb4 | | character_set_filesystem | binary | | character_set_results | utf8mb4 | | character_set_server | utf8mb4 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ Today I installed Koha 21.05.03 on Debian GNU/Linux 11 with MariaDB 10.5.11 where the character sets are as follows: MariaDB [(none)]> SHOW VARIABLES LIKE '%char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8mb4 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8mb4 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ I'm not sure what is going on here. Does anyone know why the character sets for client, connection and results have changed from utf8mb4 to utf8? Is this correct with Koha or should these character sets be changed? 2. Today I came upon an installation of Koha 18.11.05 using MariaDB 10.0.32 which has the following character sets: MariaDB [(none)]> SHOW VARIABLES LIKE '%char%'; +--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | latin1 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | latin1 | | character_set_system | utf8 | | character_sets_dir | /usr/share/mysql/charsets/ | +--------------------------+----------------------------+ This seems quite wrong to me - as far as I know "latin1" was never a supported character set in Koha... as far as I know the character sets should be set as shown in topic 1. However, is it still possible to update such a database with these character sets to Koha 21.05.03 without destroying the data completely? 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

2 2

Koha 19.11.21 released
by Wainui Witika-Park 26 Aug '21

26 Aug '21

Hello everyone! The Koha community is proud to announce the release of version 19.11.21. The full release notes can be found at: https://koha-community.org/koha-19-11-21-released/ Thank you to everyone involved! Cheers, Wainui Witika-Park (she/her)

1 0

Release of Koha 20.11.09
by Fridolin SOMERS 25 Aug '21

25 Aug '21

Hi everyone 🤗 The Koha community is proud to announce the release of Koha 20.11.09 🚀 It is a maintenance release with 1 security fix 🛠️ The full release notes are available here 📜 https://koha-community.org/koha-20-11-09-released/ The Debian packages are already available 🌼 Best regards 🌊 -- Fridolin SOMERS <fridolin.somers(a)biblibre.com> Software and system maintainer 🦄 BibLibre, France

1 0

Koha 20.05.15 released, ⚠ security release
by Victor Grousset/tuxayo 25 Aug '21

25 Aug '21

Hello! :) The Koha Community is happy to announce the release of Koha 20.05.15 The full release notes can be found at: https://koha-community.org/koha-20-05-15-released/ The Debian packages are already available. Thanks to everyone involved :) Cheers, -- Victor Grousset/tuxayo

1 0

Koha packages are available 🎁
by Mason James 25 Aug '21

25 Aug '21

kia ora community, the latest Koha packages are available cheers, Mason

1 0