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.
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.
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>
Same problem as 38030 The csrf token needs to be in the POST body or in a HTTP header.
(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?
(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 ?
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?
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>
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>
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.
Pushed for 24.11! Well done everyone, thank you!
Backported to 24.05.x for upcoming 24.05.06
Not for 23.11.x
Big fix, nothing to add/edit in the manual.