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@chetcolibrary.org Reporter: phil@chetcolibrary.org QA Contact: testopia@bugs.koha-community.org CC: dcook@prosentient.com.au, gmcharlt@gmail.com, jonathan.druart@gmail.com, kyle.m.hall@gmail.com, oleonard@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/7342209b34d642... 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.