Jonathan Druart [Tue, 13 Feb 2024 14:08:25 +0000 (15:08 +0100)]
Bug 36084: Bring fetch for everywhere
We are retrieving the awesome fetch modules from Vue, so that it can be
used in other areas. Here we will use it to inject the CSRF token to the
header of every POST request.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jonathan Druart [Mon, 12 Feb 2024 16:36:44 +0000 (17:36 +0100)]
Bug 36084: C4::Auth+plack.psgi for svc?
Suggestion to move the CSRF check to CGI->new so that we will check it
for every request, and it will cover svc scripts as well (they are not
using get_template_and_user).
The token will be retrieve from the param list *or the csrf_token
header* (do we want to name it x-koha-csrf-token instead?).
This will be done for *every* request that are not GET: CSRF token is now
required everywhere CGI is used (side-effects possible?).
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jonathan Druart [Tue, 20 Feb 2024 10:03:37 +0000 (11:03 +0100)]
Bug 36102: (follow-up) Add cud-login to the login form
Hum this didn't make sense. We are not checking credentials after
checkauth.
This patch is suggesting to rename "userid" and "password" parameters
from login forms to "login_userid" and "login_password" to not interfere
with other parameters with the same name.
This looks quite correct, however I am seeing
"The form submission failed (Wrong CSRF token)."
in the log after a successful login. Which feels wrong, what's
happening?
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Jonathan Druart [Thu, 15 Feb 2024 13:06:33 +0000 (14:06 +0100)]
Bug 36102: Fix 01-installation.t
Something very weird is happening here.
There is a FIXME already, but the trick does not seem to work anymore
(?)
This patch contains some debug statements and take some screenshots.
We are reaching the cud-selectframeworks step then we are expecting the
form to submit the form with op=cud-addframeworks
BUT it seems that "op" is empty, and there is an unexpected warning from
Starman:
==> /var/log/koha/kohadev/plack-error.log <==
""
Use of uninitialized value in string ne at /usr/share/perl5/Starman/Server.pm line 304.
==> /var/log/koha/kohadev/plack-intranet-error.log <==
[2024/02/15 13:09:34] [WARN] Warning: something's wrong at /kohadevbox/koha/installer/install.pl line 89.
What's going on here??
UPDATE: This is fixed by "Bug 34478: Manual fix - Make Koha::Token use
session id not userenv id"
Bug 36102: [TO SQUASH] Fix 01-installation.t
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Owen Leonard [Fri, 23 Feb 2024 15:30:22 +0000 (15:30 +0000)]
Bug 34478: Fixes for MARC modification template management
This patch converts several delete links to POSTed forms and corrects
the op variable names in the script. The patch also simplifies the
deletion click handlers.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Initial submissions to batch biblio operations have to accommodate
POSTed file data, so this patch makes changes to instances where we were
submitting biblionumbers in a URL.
We could also choose to make a change in tools/batch_delete_records.pl
and tools/batch_record_modification.pl to handle different "list"
operations differently based on the method of submission. This patch
presents only the client-side option.
The cart presented a unique problem in that it requires that data be
passed from the pop-up window to the parent window, something which
can't as easily be done with a form as with a URL. The workaround I came
up with is to dynamically generate the form in the parent page and
trigger the submission from there.
Also changed:
- More updated CSS to handle buttons inside dropdowns inside toolbars.
- Correct op names for the "list" operation in batch modify and delete
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Owen Leonard [Thu, 22 Feb 2024 12:10:16 +0000 (12:10 +0000)]
Bug 34478: Fix style and markup of forms within dropdowns
This patch adds some CSS for handling the style of form buttons inside
Bootstrap dropdowns and corrects related markup in two places: Authority
search results and Suggestion management.
Buttons should look correct if we avoid using <fieldset> inside
dropdowns and make sure the button has "btn btn-default" classes.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Owen Leonard [Tue, 20 Feb 2024 19:19:24 +0000 (19:19 +0000)]
Bug 34478: Item removal deletion should be POSTed form
This patch updates the "Remove" button from items which are in a
rotating collection (in the "Manage items" stage). A GET link is
converted to a posted form.
Unrelated: The JavaScript has also been modified so that it asks for
confirmation.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Owen Leonard [Tue, 20 Feb 2024 15:49:41 +0000 (15:49 +0000)]
Bug 34478: Convert patron file delete link to a posted form
This patch modifies the patron file template to convert the "Delete"
link to a form which includes the CSRF token. The script has already
been modified to check for the "op" value updated in the template.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Owen Leonard [Fri, 16 Feb 2024 14:18:06 +0000 (14:18 +0000)]
Bug 34478: Corrections to add and delete of OAI sets
This patch makes two changes: The first changes the name of the op value
matched in the script when editing a set. The "mod" step is a GET
operation to load the edit form.
The second change is a workaround for the fact that a submit
button looks bad in a Bootstrap dropdown. The patch creates a hidden
form for deletion operations. Clicking a "delete" link in a dropdown
fills the hidden form with the OAI set id to be deleted and submits it.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Owen Leonard [Thu, 15 Feb 2024 16:35:39 +0000 (16:35 +0000)]
Bug 34478: Authority frameworks - first subfield delete button has incorrect op value
From the list of a tag's subfields (e.g.
/cgi-bin/koha/admin/auth_subfields_structure.pl?tagfield=245&frameworkcode=)
the delete button is a GET operation to a second form for confirmation.
This script should be checking for op=delete_confirm, not cud-delete-confirm.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Owen Leonard [Thu, 15 Feb 2024 16:19:56 +0000 (16:19 +0000)]
Bug 34478: Frameworks - first subfield delete button has incorrect op value
From the list of a tag's subfields (e.g.
/cgi-bin/koha/admin/marc_subfields_structure.pl?tagfield=245&frameworkcode=)
the delete button is a GET operation to a second form for confirmation.
This script should be checking for op=delete_confirm, not
cud-delete-confirm.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
Martin Renvoize [Thu, 15 Feb 2024 15:25:17 +0000 (15:25 +0000)]
Bug 34478: Use op and cud in pay -> paycollect redirect
The pay to paycollect post/redirect flow here doesn't actually
consistute a state change, however it's much simpler to add the csrf
token check flow here than to refactor the code to a get (url's quickly
grow too large for a GET) or rework it in other ways. I opted to do
this for now and work on a refactor at a future date.
Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org>
projects / koha.git / log