[Bug 42095] New: UNIMARC: Cataloging plugin unimarc_field_4XX.pl broken after Bug 34478 (op-cud)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42095 Bug ID: 42095 Summary: UNIMARC: Cataloging plugin unimarc_field_4XX.pl broken after Bug 34478 (op-cud) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs@lists.koha-community.org Reporter: synapse.ova@gmail.com QA Contact: testopia@bugs.koha-community.org CC: m.de.rooy@rijksmuseum.nl The UNIMARC cataloging plugin unimarc_field_4XX.pl no longer performs searches after the implementation of CSRF protection changes in Bug 34478. The template unimarc_field_4XX.tt was updated to use op=cud-do_search to comply with the new security requirements, but the corresponding Perl script unimarc_field_4XX.pl was not updated to handle the cud- prefix or the renamed parameter. As a result, when a user clicks the "Search" button in the plugin popup, the script fails to recognize the operation and doesn't return any results. This issue specifically affects UNIMARC installations. Steps to reproduce: Use a Koha instance configured for UNIMARC. Go to Cataloging -> Add MARC record. Locate a 4XX field (e.g., 410, 411, 461) and click the plugin button (...) to open the search popup. Enter any search term (e.g., a title or author) and click "Search". Observe that the page simply reloads or shows the search form again without any results, despite matches existing in the database. Check the logic in cataloguing/value_builder/unimarc_field_4XX.pl: it likely checks for if ($op eq 'do_search'), which is now never true because the value passed is cud-do_search. Actual results: The plugin stays on the search form and does not execute the search logic. Expected results: The plugin should execute the search and display the list of records to link. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42095 Oleg Vasylenko <synapse.ova@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|major |blocker Depends on| |34478 Priority|P5 - low |P1 - high --- Comment #1 from Oleg Vasylenko <synapse.ova@gmail.com> --- Possible solution is to find in unimarc_field_4XX.pl the string elsif ( $op eq "do_search" ) { and change it to: elsif ( $op eq "do_search" || $op eq "cud-do_search" ) { Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34478 [Bug 34478] Full CSRF protection -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42095 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blawlor@clamsnet.org --- Comment #2 from Brendan Lawlor <blawlor@clamsnet.org> --- (In reply to Oleg Vasylenko from comment #1)
Possible solution is to find in unimarc_field_4XX.pl the string elsif ( $op eq "do_search" ) { and change it to: elsif ( $op eq "do_search" || $op eq "cud-do_search" ) {
See also this bug 40307 I am interested in this type of bug because I am working on updating the coding guideline for 5.1 This op was prefixed with cud- by a script as a result of bug 34478. One one hand if the request does not result in making any changes to the database, then it doesn't necessarily need to be POST and it could be changed to GET. GET could be preferred in cases where it would be convenient for users to be able to bookmark/share a url. POST would be preferred for scalability when the form needs to be able to send many parameters/values that would exceed the character limit in a url. In these cases there are examples in the codebase of ops like cud-do_search, cud-search, and cud-form I don't know enough about this unimarc plugin to know which solution is better for this case, but the similar bug 40307 has a patch changing the request to GET. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42095 --- Comment #3 from Oleg Vasylenko <synapse.ova@gmail.com> --- Thank you for the feedback and for pointing to Bug 40307. After reviewing the plugin's code and its purpose, I believe that changing the request method to GET is indeed the better solution here. The unimarc_field_4XX.pl plugin acts as a lookup tool: 1. It opens a popup with a search form. 2. The user enters search criteria (Title, Author, ISBN, etc.) to find a record in the catalog. 3. The script retrieves results and displays them. 4. Once a record is chosen, JavaScript populates the 4XX subfields in the main cataloging form. No database modifications (CUD operations) are performed during the search process. The number of parameters in the search form is also standard and unlikely to hit URL character limits. Switching to GET would: • Align with the coding guidelines for idempotent actions. • Resolve the current breakage caused by the cud- prefix mismatch between the template and the script. • Match the approach taken in Bug 40307. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42095 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m --- Comment #4 from Fridolin Somers <fridolin.somers@biblibre.com> --- Duplicate of Bug 40306 ? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42095 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=40306 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42095 Brendan Lawlor <blawlor@clamsnet.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Brendan Lawlor <blawlor@clamsnet.org> --- *** This bug has been marked as a duplicate of bug 40306 *** -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org