March 2026 - Koha-bugs - lists.koha-community.org

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '26

06 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #274 from David Cook <dcook(a)prosentient.com.au> --- Oops guess I should attach the new patch... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #273 from David Cook <dcook(a)prosentient.com.au> --- (In reply to David Cook from comment #271) > (In reply to Jonathan Druart from comment #265) > > (In reply to David Cook from comment #258) > > > (In reply to Jonathan Druart from comment #253) > > > > Ok, however I found more: > > > > Caught by the xt tests (and now by add_csp_nonces.pl as well) > > > > * t/lib/plugins/Koha/Plugin/TestValuebuilder/test_valuebuilder_popup.tt > > > > > > So this is an interesting one. I will upload a patch for this one, but it's > > > going to work differently to what you might expect. I'll explain more in my > > > response to your comment about cataloguing plugins. > > > > > > (To test this one, you'll want to run `prove > > > t/db_dependent/Koha/Plugins/Valuebuilder_hooks.t`) > > > > xt/find-missing-nonce.t is still failing on this file then. Should we > > exclude it? > > I think that we should exclude it, since it's good at testing that > Koha::FrameworkPlugin is working correctly at this time. Hmm... I looked at adding an exclusion but not sure how we do it. If we change Koha::Devel::Files->ls_tt_files to exclude that test template, won't we be excluding it from other scripts perhaps should include it? It would be good to be able to provide runtime exceptions to ls_tt_files() and friends. What do you think, Jonathan? (It wouldn't be the end of the world if we did add a nonce to test_valuebuilder_popup.tt, but it probably is good to also be able to provide future exceptions anyway.) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #272 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Jonathan Druart from comment #267) > (In reply to Jonathan Druart from comment #265) > > (In reply to David Cook from comment #258) > > > (In reply to Jonathan Druart from comment #253) > > > > And those ones when testing the UI: > > > > * cataloguing/value_builder/* (oops, all cataloguing plugins are broken) > > > > We might need to adjust the xt test and add_csp_nonces.pl to caught those > > > > files as well. > > > > > > So these aren't actually broken. When I was first working on the patches, I > > > thought they would be, but the script tags are actually already re-written > > > by Koha/FrameworkPlugin.pm, so it adds the nonce to them. If you try out the > > > cataloguing plugins, they should all work without any violation reports. See > > > the patch labelled "Bug 38365: Fix nonce caching and add to framework plugin > > > scripts". > > > > I do see dozens of violations in the console when I edit a biblio: > > https://snipboard.io/X7OYJp.jpg > > I cannot clone a subfield. > And plugins don't work (tried with 100$a) Is this when you're in "report-only" mode or in "enabled" mode? If you're in "enabled" mode, then yeah you'll have a number of problems in the intranet/staff interface, since it is still using inline event handlers. (As I note in my above comment, the 100$a doesn't use a plugin. It uses an inline event handler. The plugins used by things like the leader and 008 are fine.) -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #271 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Jonathan Druart from comment #265) > (In reply to David Cook from comment #258) > > (In reply to Jonathan Druart from comment #253) > > > > > 7. When enabled, I see an error in the browser's console: > > > > > Content-Security-Policy: The page’s settings blocked the loading of a > > > > > resource (media-src) at data: because it violates the following directive: > > > > > “default-src 'self'” > > > > > > > > That's interesting. I'd like to hear more about this one. Were there > > > > additional details? I wonder if it had to do with audio when doing a > > > > checkout or something? > > > > > > No idea! There is nothing else! Don't you see it? > > > > Nope! I haven't been able to find it. I don't see it anywhere. Does it > > happen on a particular page? > > All pages: https://snipboard.io/if28Qu.jpg Yeah, I don't see that on mine: https://snipboard.io/GSboJW.jpg media-src is for <audio> and <video> elements, also even that violation message looks weird, although I see other people talking about it online. Do you have any browser plugins/extensions? I think something in your browser is injecting audio/video into your pages. > > > Ok, however I found more: > > > Caught by the xt tests (and now by add_csp_nonces.pl as well) > > > * t/lib/plugins/Koha/Plugin/TestValuebuilder/test_valuebuilder_popup.tt > > > > So this is an interesting one. I will upload a patch for this one, but it's > > going to work differently to what you might expect. I'll explain more in my > > response to your comment about cataloguing plugins. > > > > (To test this one, you'll want to run `prove > > t/db_dependent/Koha/Plugins/Valuebuilder_hooks.t`) > > xt/find-missing-nonce.t is still failing on this file then. Should we > exclude it? I think that we should exclude it, since it's good at testing that Koha::FrameworkPlugin is working correctly at this time. > > > And those ones when testing the UI: > > > * cataloguing/value_builder/* (oops, all cataloguing plugins are broken) > > > We might need to adjust the xt test and add_csp_nonces.pl to caught those > > > files as well. > > > > So these aren't actually broken. When I was first working on the patches, I > > thought they would be, but the script tags are actually already re-written > > by Koha/FrameworkPlugin.pm, so it adds the nonce to them. If you try out the > > cataloguing plugins, they should all work without any violation reports. See > > the patch labelled "Bug 38365: Fix nonce caching and add to framework plugin > > scripts". > > I do see dozens of violations in the console when I edit a biblio: > https://snipboard.io/X7OYJp.jpg So those are different violations unrelated to the nonces. Those are due to inline event handlers, and bug 38407 is for fixing those. If you try the cataloguing plugins for the leader and 008, they're fine. Same with the item editor. The "tag editor" for 100$a isn't using a cataloguing plugin. It's using an inline event handler. These inline event handlers need to be moved into <script> elements with nonces or moved into separate files. But that's what bug 38407 is for. > > I think an argument could be made for fixing them a different way... and you > > just reminded me of why I used an ENV variable initially. It was for this. > > When the plugins get launched the CGI context gets re-set which is why I > > lost the cached values, but the ENV variable would persist and the package > > level variable are fine. > > > > > Also wondering if this one won't require adjustment: > > > misc/devel/tidy.pl:172 $content =~ s#\n*( > > > *)<script>\n*#\n$1<script>\n#g; > > > > Yeah I guess so since it won't match. I've written a patch that will cover > > this (as well as a future where we have other attributes like type for ESM > > modules or use async or defer). > > Hum I've revert your patch and tried to see how it broke the tidy but it > didn't. All good but maybe this is no longer needed. Will keep in mind if > some tidy errors appear in the next weeks. I was wondering that too. That bit of tidying is just collapsing multiple new lines into a single new line, so I'm not sure it's that helpful? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #270 from David Cook <dcook(a)prosentient.com.au> --- (In reply to David Cook from comment #269) > (In reply to Lari Taskula from comment #268) > > (In reply to Jonathan Druart from comment #266) > > > Patch application failed for attachment 194449 [details] [review] [review] [review] - Bug > > > 38365: Make swagger-cli happy > > > > > > > > > failed: error: sha1 information is lacking or useless > > > (api/v1/swagger/definitions/csp_report.yaml). > > Hmm all patches apply cleanly for me, using git-bz. > > > > On top of c3cf41c275695d260c5397e7cfbd4cf83e60fa9c > > Yeah, I tried an apply yesterday of all the patches on main and it applied > cleanly. I'll take another look today though when I'm looking into the other > things. I would've sworn I was up-to-date on main, and I don't have any updates to fetch this morning, but it looks like I'm 52 commits behind somehow. Weird. I'll get fresh patches posted. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38365] Add Content-Security-Policy HTTP header to HTML responses
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38365 --- Comment #269 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Lari Taskula from comment #268) > (In reply to Jonathan Druart from comment #266) > > Patch application failed for attachment 194449 [details] [review] [review] - Bug > > 38365: Make swagger-cli happy > > > > > > failed: error: sha1 information is lacking or useless > > (api/v1/swagger/definitions/csp_report.yaml). > Hmm all patches apply cleanly for me, using git-bz. > > On top of c3cf41c275695d260c5397e7cfbd4cf83e60fa9c Yeah, I tried an apply yesterday of all the patches on main and it applied cleanly. I'll take another look today though when I'm looking into the other things. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 42007] New: Add API path to get count of active holds on a biblio
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42007 Bug ID: 42007 Summary: Add API path to get count of active holds on a biblio Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, lisette(a)bywatersolutions.com, tomascohen(a)gmail.com Right now the only way to find out if there's record level holds on a record is to GET holds/?biblio_id={id}, integrations (such as for interlibrary loan) might need to see if there's holds on the record that would fill the hold sooner so it can look for a different supplier. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 40204] New: Add examples of 200 request in API documentation for list biblios, get biblio, list deleted biblio, get deleted biblio, get biblio (public)
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40204 Bug ID: 40204 Summary: Add examples of 200 request in API documentation for list biblios, get biblio, list deleted biblio, get deleted biblio, get biblio (public) Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)openfifth.co.uk, philip.orr(a)lmscloud.de There is no example of 200 requests for those routes in the documentation -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 39267] New: Specified due date remains for checkouts even when removing unchecking remember for session
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39267 Bug ID: 39267 Summary: Specified due date remains for checkouts even when removing unchecking remember for session Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When checking out an item for a borrower, choosing a specific due date and checking the "remember for session". If another checkout is done, removing the date and unchecking "remember for session", after the checkout has been performed, the previously set due date is still there. It's difficult to see how the correct behaviour shouldn't be that the date is cleared from the session as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11

[Bug 39452] New: Log cardnumber changes as distinct action within borrower logs
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '26

05 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=39452 Bug ID: 39452 Summary: Log cardnumber changes as distinct action within borrower logs Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 18626 Libraries find it useful to retain previous patron cardnumbers. Long ago, bug 18626 started retaining those old cardnumbers in the action logs. But action logs contain a lot of other data a library may not wish to retain indefinitely. Cleanup_database can specify deletion/retention of logs down to the action level, so making cardnumber changes a distinct action would make is easy to retain cardnumber changes in the logs without retaining other data. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18626 [Bug 18626] Add ability to track cardnumber changes for patrons -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27