January 2025 - Koha-bugs - lists.koha-community.org

[Bug 37887] New: OPAC password recovery needs to use a cud- op while POSTing new password
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37887 Bug ID: 37887 Summary: OPAC password recovery needs to use a cud- op while POSTing new password Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: OPAC Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 Blocks: 37728 The intention of the CSRF protection from bug 36192 was that any form that used method="post" would have to have a param named 'op' which started with 'cud-' but the test that verifies they do missed the case of a template with more than one form. Bug 37728 corrects that, but to land, the things that currently fail the test need to be fixed. In opac-password-recovery.tt that's the fairly critical step where the user sets a new password. Luckily, getting there requires the uniqueKey that's sent in the recovery email, and if someone has access to that you've already lost the game, so it's not really a security issue, just something that needs to be fixed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 37853] New: Returning to your account at the end of changing your password in the OPAC doesn't need to POST a form
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37853 Bug ID: 37853 Summary: Returning to your account at the end of changing your password in the OPAC doesn't need to POST a form Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: OPAC Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 Blocks: 37728 The end of the UI flow of changing your password in the OPAC is a page which tells you your password was changed (good, you need to know it's time to log out and back in to change your saved password, or that it's time to scribble out the old one on a Post-it and write down the new one), and then offers to take you back to your account with a button in a form which does a POST to opac-user.pl without an op and with your borrowernumber, which is double-bad. We intend not to allow POST without an op, and once the test is fixed in bug 37728 this will fail, and there's no need for the borrowernumber since it will be completely ignored by the script, which will instead get it from your cookie or make you log in. Instead of a form+button+POST, it should just be a link. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 37827] New: Switch OPAC download list form from POST to GET
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37827 Bug ID: 37827 Summary: Switch OPAC download list form from POST to GET Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: OPAC Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 Blocks: 37728 We meant to not have any forms that post without an op starting with cud-, but because of bug 37728 we missed a few, like the hidden form to download a list in the OPAC. There's no visible reason why it even needs a form to submit, rather than just having the menu be a list of links the way the staff client does it, but that's a problem for another bug. Here, we just need to switch it from a post to a get, so we can land the fix to the test for things posting without a cud- op. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 37794] New: Fix form that POSTs without an op in Holds to pull
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37794 Bug ID: 37794 Summary: Fix form that POSTs without an op in Holds to pull Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Circulation Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 36192 Blocks: 37728 We intend not to have forms with method="post" without an op variable (so we can check that the op starts with "cud-" as part of the CSRF protection), but because of bug 37728 some were missed. In Holds to pull, that's the form that lets you choose different start and end dates. Having it do a GET instead doesn't add much bookmark or link benefit, since the params are actual dates rather than something like -5d, but at least it lets you refresh the page without a browser warning about repeating a POST. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 37785] New: Remove dead code in tools/letter.tt that looks like a form that would POST without an op
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37785 Bug ID: 37785 Summary: Remove dead code in tools/letter.tt that looks like a form that would POST without an op Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Tools Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 Blocks: 37728 We intend not to have forms with method="post" without an op variable (so we can check that the op starts with "cud-" as part of the CSRF protection), but because of bug 37728 some were missed. In tools/letter.tt that's two forms, https://git.koha-community.org/Koha-community/Koha/src/commit/4f52463551632… which is shown IF ( add_validate or copy_validate) and one a bit further down at #L594 which is shown IF ( delete_confirmed ). To someone that knows how are templates work, that would sound like either the op which wants to show them would be add_validate or copy_validate or delete_confirmed, or more likely in the current era it would be cud-add_validate etc., which either sets the param add_validate, or was broken by the change to cud-ops. These two are different, though. If you look back through blame history for every change to letter.pl for the ops in question, they have never, ever, let their op be defined for a template to show a confirmation message. Currently they do "$op = q{}; # we return to the default screen for the next operation", if you go back to the dawn of time, prior to rel_3_0 moved to HEAD, they started out doing "print $input->redirect("letter.pl");". I'd like to have a better term than "dead code" for something which has been unreachable since it was copy-pasted from some other template, but I can't come up with an inoffensive one. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 37769] New: Fix forms that POST without an op in currency administration
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37769 Bug ID: 37769 Summary: Fix forms that POST without an op in currency administration Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: System Administration Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36192 Blocks: 37728 We intend not to have forms with method="post" without an op variable (so we can check that the op starts with "cud-" as part of the CSRF protection), but because of bug 37728 some were missed. In Currency and exchange rate administration, that's the "OK" button that takes you back to the list when you try to delete a currency in use by a vendor, which doesn't need to POST, and the OK button in the confirmation page after you delete a currency, which currently doesn't actually show at all, but when it does doesn't need to POST since it just takes you back to the list of currencies. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 37779] New: Fix forms that POST without an op in tag moderation
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37779 Bug ID: 37779 Summary: Fix forms that POST without an op in tag moderation Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Tools Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 36192 Blocks: 37728 We intend not to have forms with method="post" without an op variable (so we can check that the op starts with "cud-" as part of the CSRF protection), but because of bug 37728 some were missed. In tag moderation, there are two: the fallback form for testing whether a word has been approved or rejected when JavaScript is disabled so the normal AJAX code doesn't run (a brutal thing to write a test plan for), and the Filters form, which by POSTing prevents you from bookmarking the page for all reviews by a particular person, or all rejected tags, or anything else you might want to check without having to recreate the filter. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 37783] New: Fix form that looks like it would POST without an op in reserve/request.tt
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37783 Bug ID: 37783 Summary: Fix form that looks like it would POST without an op in reserve/request.tt Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: Circulation Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: dcook(a)prosentient.com.au, gmcharlt(a)gmail.com, jonathan.druart(a)gmail.com, kyle.m.hall(a)gmail.com, oleonard(a)myacpl.org Depends on: 36192 Blocks: 37728 We intend not to have forms with method="post" without an op variable (so we can check that the op starts with "cud-" as part of the CSRF protection), but because of bug 37728 some were missed. One that the patched xt/find-missing-op-in-forms.t points at is the rather odd https://git.koha-community.org/Koha-community/Koha/src/commit/7342209b34d64… which isn't actually a standalone form: if you could submit it any way other than after the JavaScript at #L1851 alters it, it wouldn't actually do anything since it lacks both the op cud-cancel and also the reserve_id that it has to have to cancel a reserve. Assuming there's no real reason to have the JavaScript add the op, we could put it immediately after the [% INCLUDE 'csrf-token.inc' %] where it would usually be, but the funnier alternative is to put it inside the <div id="inputs"> for the test to see, and then since the first thing the JavaScript does is to .empty() that div before it puts it back in, the behavior would be unchanged but the test (and someone casually scanning the code) could see what the op will be without having to know that it will be deleted and then added right back. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 37767] New: Fix forms that POST without an op in Authority types
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37767 Bug ID: 37767 Summary: Fix forms that POST without an op in Authority types Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36192 Blocks: 37728 We intend not to have forms with method="post" without an op variable (so we can check that the op starts with "cud-" as part of the CSRF protection), but because of bug 37728 some were missed. In Authority types (the odd name for MARC authority frameworks), that's the "No, do not delete" cancel button when you decide not to go through with deleting a tag, which doesn't need to POST since all it does is take you back to where you were, and the OK button in the page that tells you the tag was deleted when you decide to go ahead, which currently doesn't even show, but when it does, it doesn't need to POST because it's just taking you back to where you were. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 37766] New: Fix forms that POST without an op in MARC bibliographic frameworks
by bugzilla-daemon＠bugs.koha-community.org 21 Feb '25

21 Feb '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37766 Bug ID: 37766 Summary: Fix forms that POST without an op in MARC bibliographic frameworks Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: System Administration Assignee: phil(a)chetcolibrary.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 36192 Blocks: 37728 We intend not to have forms with method="post" without an op variable (so we can check that the op starts with "cud-" as part of the CSRF protection), but because of bug 37728 some were missed. In MARC bibliographic frameworks, that's the tag search form, which is very much not something that should or needs to POST, and doing so prevents bookmarking or linking to a search for a particular tag, and the cancel "No, do not delete" button in the confirmation page while deleting a subfield, which doesn't need to POST because it doesn't need to send anything other than what's needed to go back to where you were. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36192 [Bug 36192] [OMNIBUS] CSRF Protection for Koha https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37728 [Bug 37728] More "op" are missing in POSTed forms -- You are receiving this mail because: You are watching all bug changes.

1 19