Bug 37767 - Fix forms that POST without an op in Authority types
Summary: Fix forms that POST without an op in Authority types
Status: Passed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: Main
Hardware: All All
: P3 normal
Assignee: Phil Ringnalda
QA Contact: Testopia
URL:
Keywords:
Depends on: 36192
Blocks: 37728
  Show dependency treegraph
 
Reported: 2024-08-29 03:49 UTC by Phil Ringnalda
Modified: 2024-09-16 11:54 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 37767: Fix forms that POST without an op in Authority types (3.35 KB, patch)
2024-08-30 00:49 UTC, Phil Ringnalda
Details | Diff | Splinter Review
Bug 37767: Fix forms that POST without an op in Authority types (3.42 KB, patch)
2024-09-09 16:35 UTC, Sukhmandeep
Details | Diff | Splinter Review
Bug 37767: Fix forms that POST without an op in Authority types (3.49 KB, patch)
2024-09-16 11:54 UTC, Jonathan Druart
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Phil Ringnalda 2024-08-29 03:49:15 UTC
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.
Comment 1 Phil Ringnalda 2024-08-30 00:21:07 UTC
Lesson learned: don't try to file multiple near-identical bugs late in the evening, you'll confuse them.

The two forms in Authority types are the cancel button when you decide not to delete a tag, and the search for tags form (there is no confirmation page after deleting a tag).
Comment 2 Phil Ringnalda 2024-08-30 00:32:35 UTC
Sigh.

There is a delete confirm page, and it doesn't show because auth_tag_structure.pl just does a print $input->redirect() and exits after deleting a tag.

The cancel button when you decide not to delete a tag has already been switched to a get.

The copy-pasted but not kept in sync duplicated code between Authority types and MARC bibliographic frameworks is annoying.

The two forms that POST without an op are dead code in the template for a delete confirm page, and the search for tags, which like MARC bibliographic frameworks in bug 37766 should be a GET so you can bookmark or link to searches for a particular tag in a particular framework.
Comment 3 Phil Ringnalda 2024-08-30 00:49:59 UTC
Created attachment 170894 [details] [review]
Bug 37767: Fix forms that POST without an op in Authority types

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, that's dead code in the template that expects to show a
"Data deleted" confirmation page, but it never shows because rather than
setting the variable delete_confirmed and outputting the template, the op
cud-delete_confirmed just does a print $input->redirect() and exits, and, the
search for tags form that should be a GET so it can be bookmarked and linked
to.

Test plan:
 1. Without the patch, Administration - Authority types - choose one other
    than default, so you can see the code rather than "" in the URL -
    Actions - MARC structure
 2. For any tag (you *are* testing in a throwaway database, right?) click
    Actions - Delete then Yes, delete
 3. Note that you don't get a confirmation page, just redirected back to a
    search for your tag which no longer exists, with the searchfield and
    authtypecode nicely in the URL
 4. Click the Search button for the Search for tag form, without changing
    anything
 5. Note that your URL lost the searchfield and authtypecode
 6. Apply patch, restart_all
 7. Repeat steps 1, 2, and 3, with identical results like they should be
 8. Repeat step 4, but this time note that the searchfield and authtypecode
    stay in the URL.
 9. Change the select menu for In framework and click Search, note that
    the searchfield and frameworkcode are still in the URL and still correct
    and that the correct results show
10. Change the tag number and hit Enter, and verify that the URL and the
    page show the correct results

Sponsored-by: Chetco Community Public Library
Comment 4 Phil Ringnalda 2024-08-30 00:54:40 UTC
And yes, after all my confusion about what I was fixing here, I did apply the patch from bug 37728 on top of my patch and verify that xt/find-missing-op-in-forms.t was no longer finding any in auth_tag_structure.tt :)
Comment 5 Sukhmandeep 2024-09-09 16:35:52 UTC
Created attachment 171216 [details] [review]
Bug 37767: Fix forms that POST without an op in Authority types

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, that's dead code in the template that expects to show a
"Data deleted" confirmation page, but it never shows because rather than
setting the variable delete_confirmed and outputting the template, the op
cud-delete_confirmed just does a print $input->redirect() and exits, and, the
search for tags form that should be a GET so it can be bookmarked and linked
to.

Test plan:
 1. Without the patch, Administration - Authority types - choose one other
    than default, so you can see the code rather than "" in the URL -
    Actions - MARC structure
 2. For any tag (you *are* testing in a throwaway database, right?) click
    Actions - Delete then Yes, delete
 3. Note that you don't get a confirmation page, just redirected back to a
    search for your tag which no longer exists, with the searchfield and
    authtypecode nicely in the URL
 4. Click the Search button for the Search for tag form, without changing
    anything
 5. Note that your URL lost the searchfield and authtypecode
 6. Apply patch, restart_all
 7. Repeat steps 1, 2, and 3, with identical results like they should be
 8. Repeat step 4, but this time note that the searchfield and authtypecode
    stay in the URL.
 9. Change the select menu for In framework and click Search, note that
    the searchfield and frameworkcode are still in the URL and still correct
    and that the correct results show
10. Change the tag number and hit Enter, and verify that the URL and the
    page show the correct results

Sponsored-by: Chetco Community Public Library
Signed-off-by: Sukhmandeep Benipal <sukhmandeep.benipal@inLibro.com>
Comment 6 Jonathan Druart 2024-09-16 11:54:36 UTC
Created attachment 171537 [details] [review]
Bug 37767: Fix forms that POST without an op in Authority types

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, that's dead code in the template that expects to show a
"Data deleted" confirmation page, but it never shows because rather than
setting the variable delete_confirmed and outputting the template, the op
cud-delete_confirmed just does a print $input->redirect() and exits, and, the
search for tags form that should be a GET so it can be bookmarked and linked
to.

Test plan:
 1. Without the patch, Administration - Authority types - choose one other
    than default, so you can see the code rather than "" in the URL -
    Actions - MARC structure
 2. For any tag (you *are* testing in a throwaway database, right?) click
    Actions - Delete then Yes, delete
 3. Note that you don't get a confirmation page, just redirected back to a
    search for your tag which no longer exists, with the searchfield and
    authtypecode nicely in the URL
 4. Click the Search button for the Search for tag form, without changing
    anything
 5. Note that your URL lost the searchfield and authtypecode
 6. Apply patch, restart_all
 7. Repeat steps 1, 2, and 3, with identical results like they should be
 8. Repeat step 4, but this time note that the searchfield and authtypecode
    stay in the URL.
 9. Change the select menu for In framework and click Search, note that
    the searchfield and frameworkcode are still in the URL and still correct
    and that the correct results show
10. Change the tag number and hit Enter, and verify that the URL and the
    page show the correct results

Sponsored-by: Chetco Community Public Library
Signed-off-by: Sukhmandeep Benipal <sukhmandeep.benipal@inLibro.com>

Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>