Bug 38065 - Auto control number (001) widget in advanced editor does not work under CSRF protection
Summary: Auto control number (001) widget in advanced editor does not work under CSRF ...
Status: Pushed to main
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low normal
Assignee: Janusz Kaczmarek
QA Contact: David Cook
URL:
Keywords:
Depends on:
Blocks: 36192
  Show dependency treegraph
 
Reported: 2024-10-02 17:49 UTC by Janusz Kaczmarek
Modified: 2024-10-22 10:10 UTC (History)
3 users (show)

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


Attachments
Bug 38065: Auto control number (001) widget in advanced editor does not work under CSRF protection (2.38 KB, patch)
2024-10-02 18:11 UTC, Janusz Kaczmarek
Details | Diff | Splinter Review
Bug 38065: Auto control number (001) widget in advanced editor does not work under CSRF protection (2.43 KB, patch)
2024-10-02 21:03 UTC, Roman Dolny
Details | Diff | Splinter Review
Bug 38065: Auto control number (001) widget in advanced editor does not work under CSRF protection (2.48 KB, patch)
2024-10-22 00:33 UTC, David Cook
Details | Diff | Splinter Review
Bug 38065: (QA follow-up) Move csrf_token to POST body from URL (1.74 KB, patch)
2024-10-22 00:33 UTC, David Cook
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Janusz Kaczmarek 2024-10-02 17:49:50 UTC
Auto control number (001) widget in advanced editor does not work under CSRF protection.  A token should be passed to POST ... control_num_sequences call.
Comment 1 Janusz Kaczmarek 2024-10-02 18:11:31 UTC
Created attachment 172326 [details] [review]
Bug 38065: Auto control number (001) widget in advanced editor does not work under CSRF protection

Auto control number (001) widget in advanced editor does not work under
CSRF protection.  A token should be passed to POST ...
control_num_sequences call.

Test plan:
==========

1. Verify that the CONTROL_NUM_SEQUENCE category in authorized values is
   present.
3. Add a new authorized value for CONTROL_NUM_SEQUENCE:
     b) authorised value: sprLib0001
     c) in Description - a short string indicating the type of control
     number i.e. "Springfield Library"
4. Create a new bib record using the advanced editor, insert a 001
   field, note that the 001 widget is there.  Click on "Assign next". There
   should be no effect (and you could see [HTTP/1.1 403 Forbidden 706ms] in
   the browser console).
5. Apply the patch ; restart_all ; reload the browser.
6. Repeat p. 4.  You should get the content of the 001 field generated
   by the widget.
Comment 2 Roman Dolny 2024-10-02 21:03:56 UTC
Created attachment 172333 [details] [review]
Bug 38065: Auto control number (001) widget in advanced editor does not work under CSRF protection

Auto control number (001) widget in advanced editor does not work under
CSRF protection.  A token should be passed to POST ...
control_num_sequences call.

Test plan:
==========

1. Verify that the CONTROL_NUM_SEQUENCE category in authorized values is
   present.
3. Add a new authorized value for CONTROL_NUM_SEQUENCE:
     b) authorised value: sprLib0001
     c) in Description - a short string indicating the type of control
     number i.e. "Springfield Library"
4. Create a new bib record using the advanced editor, insert a 001
   field, note that the 001 widget is there.  Click on "Assign next". There
   should be no effect (and you could see [HTTP/1.1 403 Forbidden 706ms] in
   the browser console).
5. Apply the patch ; restart_all ; reload the browser.
6. Repeat p. 4.  You should get the content of the 001 field generated
   by the widget.

Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Comment 3 David Cook 2024-10-21 03:55:23 UTC
Same problem as 38030

The csrf token needs to be in the POST body or in a HTTP header.
Comment 4 Katrin Fischer 2024-10-21 11:22:13 UTC
(In reply to David Cook from comment #3)
> Same problem as 38030
> 
> The csrf token needs to be in the POST body or in a HTTP header.

It looks like we should maybe open an Omnibus and check all value builders for this issue?
Comment 5 Marcel de Rooy 2024-10-21 11:50:49 UTC
(In reply to Katrin Fischer from comment #4)
> (In reply to David Cook from comment #3)
> > Same problem as 38030
> > 
> > The csrf token needs to be in the POST body or in a HTTP header.
> 
> It looks like we should maybe open an Omnibus and check all value builders
> for this issue?

That seems to be unneeded? This is about a POST that might be possible to convert to a GET ?
Comment 6 Janusz Kaczmarek 2024-10-21 17:18:44 UTC
The plugin modifies the content of the database (it updates a row in the authorised_values table), so as for a CUD operation POST is right?
Comment 7 David Cook 2024-10-22 00:33:18 UTC
Created attachment 173084 [details] [review]
Bug 38065: Auto control number (001) widget in advanced editor does not work under CSRF protection

Auto control number (001) widget in advanced editor does not work under
CSRF protection.  A token should be passed to POST ...
control_num_sequences call.

Test plan:
==========

1. Verify that the CONTROL_NUM_SEQUENCE category in authorized values is
   present.
3. Add a new authorized value for CONTROL_NUM_SEQUENCE:
     b) authorised value: sprLib0001
     c) in Description - a short string indicating the type of control
     number i.e. "Springfield Library"
4. Create a new bib record using the advanced editor, insert a 001
   field, note that the 001 widget is there.  Click on "Assign next". There
   should be no effect (and you could see [HTTP/1.1 403 Forbidden 706ms] in
   the browser console).
5. Apply the patch ; restart_all ; reload the browser.
6. Repeat p. 4.  You should get the content of the 001 field generated
   by the widget.

Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl>
Signed-off-by: David Cook <dcook@prosentient.com.au>
Comment 8 David Cook 2024-10-22 00:33:21 UTC
Created attachment 173085 [details] [review]
Bug 38065: (QA follow-up) Move csrf_token to POST body from URL

Signed-off-by: David Cook <dcook@prosentient.com.au>
Comment 9 David Cook 2024-10-22 00:34:12 UTC
Nothing to see here folks >_>.

Janusz was right. Only issue was where the csrf_token was located in the HTTP request. (And should've used the meta element instead of the input element.)

Passed QA.
Comment 10 Katrin Fischer 2024-10-22 10:10:06 UTC
Pushed for 24.11!

Well done everyone, thank you!