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: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
CC: [email protected]
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.
_______________________________________________
Koha-bugs mailing list
[email protected]
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
