https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37765 Bug ID: 37765 Summary: Fix forms that POST without an op in systempreferences Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: System Administration Assignee: phil@chetcolibrary.org Reporter: phil@chetcolibrary.org QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com Depends on: 36192 Blocks: 37728 There are two forms that have action="post" but do not send an op (so it can't be checked for whether its value starts with 'cud-') in systempreferences. Because of bug 37728, they weren't caught earlier. One is simple, the "No, do not delete" button while starting to delete a local preference. It doesn't need to post, and changing it to a get has no behavior change. The other is slightly more complicated: the "Yes, delete" button is supposed to then show a page saying "Data deleted" with a button to take you "Back to system preferences" but changing the op to cud-delete_confirmed left the part of the template unused, because it still thinks that delete_confirmed will be true when it needs to show that. Once the script sets delete_confirmed, the "Back to system preferences" button can just be a get. 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.