[Bug 37041] New: Logging into addbiblio.pl triggers a 403
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Bug ID: 37041 Summary: Logging into addbiblio.pl triggers a 403 Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs@lists.koha-community.org Reporter: dcook@prosentient.com.au QA Contact: testopia@bugs.koha-community.org As Michal Kula noted on Mattermost, trying to log into http://localhost:8081/cgi-bin/koha/cataloguing/addbiblio.pl?biblionumber=990... in main will yield a bizarre HTTP response that includes headers for a 403 response and a 200 response... This is partially due to bug 37040, but it's mostly due to a bug in addbiblio.pl where the form builder is generating a 403 that gets printed before the 200 response somehow... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #1 from David Cook <dcook@prosentient.com.au> --- If I capture STDOUT around a subsection of build_tabs(), I get 10 of these messages in STDOUT: [2024/06/06 01:12:47] [WARN] Status: 403 Forbidden Content-Type: text/plain; charset=ISO-8859-1 Status: 403 Forbidden Content-Type: text/plain; charset=ISO-8859-1 -- I suspect is has something to do with these warnings: [2024/06/06 00:08:33] [WARN] ERROR: Plugin marc21_orgcode.pl: ARRAY(0x561ffb8bfa98) at /kohadevbox/koha/Koha/UI/Form/Builder/Biblio.pm line 222. [2024/06/06 00:08:33] [WARN] ERROR: Plugin marc21_field_005.pl: ARRAY(0x561ffb8cdb60) at /kohadevbox/koha/Koha/UI/Form/Builder/Biblio.pm line 222. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |24879 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24879 [Bug 24879] Add missing authentication checks -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=37040 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #2 from David Cook <dcook@prosentient.com.au> --- Looks like a regression caused by bug 24879 Note that I'm not planning on working on this one. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #3 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to David Cook from comment #1)
I suspect is has something to do with these warnings:
[2024/06/06 00:08:33] [WARN] ERROR: Plugin marc21_orgcode.pl: ARRAY(0x561ffb8bfa98) at /kohadevbox/koha/Koha/UI/Form/Builder/Biblio.pm line 222. [2024/06/06 00:08:33] [WARN] ERROR: Plugin marc21_field_005.pl: ARRAY(0x561ffb8cdb60) at /kohadevbox/koha/Koha/UI/Form/Builder/Biblio.pm line 222.
Seeing those too. Will have a look. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #4 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- The arrays mentioned just contain: $VAR2 = [ 'EXIT ', 0 ]; This is just caused by the new CGI on bug 24879. Easier to replace that by blocking direct access to valuebuilder scripts. See my comment there. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #5 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Marcel de Rooy from comment #4)
The arrays mentioned just contain: $VAR2 = [ 'EXIT ', 0 ];
This is just caused by the new CGI on bug 24879. Easier to replace that by blocking direct access to valuebuilder scripts. See my comment there.
To clarify: The new CGI makes that the wrong session ID is checked and that the builder scripts bail out with 403. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #6 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- For my understanding of the urgency of this: if you log in from another page or the normal "main" login page this problem doesn't occur? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #7 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #6)
For my understanding of the urgency of this: if you log in from another page or the normal "main" login page this problem doesn't occur?
Yeah thats true. So the impact is small. But our catalogers are constantly on those pages and when their session times out, they come across it. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #8 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think in this case we might keep this one open for the next regular maintenance release - still high priority to fix, but I don't want to interrupt release process. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@gmail.com --- Comment #9 from Jonathan Druart <jonathan.druart@gmail.com> --- There is something fundamentally wrong in the way we handle the session id. Which leads to this kind of problems. Should we consider setting the session id in the L1 (actually in the userenv) so that we could have access to the current session id. So if a new one has been generated and is different than the one in the cookie of the request we can access it easily? We would have then: check_cookie_auth( C4::context->{userenv}->{session_id}, $required_flags ); and not relying on CGI. Another way would be to trick CGI and replace HTTP_COOKIE env var. But this seems very hacky and certainly not something recommended. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #10 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #9)
There is something fundamentally wrong in the way we handle the session id. Which leads to this kind of problems.
Should we consider setting the session id in the L1 (actually in the userenv) so that we could have access to the current session id. So if a new one has been generated and is different than the one in the cookie of the request we can access it easily?
We would have then: check_cookie_auth( C4::context->{userenv}->{session_id}, $required_flags ); and not relying on CGI.
Another way would be to trick CGI and replace HTTP_COOKIE env var. But this seems very hacky and certainly not something recommended.
Looks easier to remove the newly added CGI in the value_builder scripts and block access in another way (RewriteRule or just move the files?). The original design should not have used scripts here .. The tric with passing another session id feels hacky too? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #11 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Marcel de Rooy from comment #10)
(In reply to Jonathan Druart from comment #9)
There is something fundamentally wrong in the way we handle the session id. Which leads to this kind of problems.
Should we consider setting the session id in the L1 (actually in the userenv) so that we could have access to the current session id. So if a new one has been generated and is different than the one in the cookie of the request we can access it easily?
We would have then: check_cookie_auth( C4::context->{userenv}->{session_id}, $required_flags ); and not relying on CGI.
Another way would be to trick CGI and replace HTTP_COOKIE env var. But this seems very hacky and certainly not something recommended.
Looks easier to remove the newly added CGI in the value_builder scripts and block access in another way (RewriteRule or just move the files?).
Easier maybe but then we have something specific in the apache config we could avoid. I am asking if there is something "better", not "easier" ;)
The original design should not have used scripts here ..
Yes, but too late.
The tric with passing another session id feels hacky too?
It is not another session id, it is actually the *current* session id! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #9)
Should we consider setting the session id in the L1 (actually in the userenv) so that we could have access to the current session id. So if a new one has been generated and is different than the one in the cookie of the request we can access it easily?
I'm not aware of the exact code problem, but this sounds all right to me. If it were a MVC like Catalyst/Mojo, we'd have something like $c->user or $c->session, so C4::Context->userenv is probably our next best thing (for now)? One day we'll move away from CGI scripts (even ones wrapped with Plack::App::CGIBin)... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #13 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 171931 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=171931&action=edit Bug 37041: Store session_id in userenv -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #14 from Jonathan Druart <jonathan.druart@gmail.com> --- Created attachment 171932 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=171932&action=edit Bug 37041: Use session_id from userenv instead of cookie for value_builder -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #15 from Jonathan Druart <jonathan.druart@gmail.com> --- Only to share what I had in mind. It fixes the problem it seems, but can eventually introduce new ones... Now the session's id is stored in userenv, so we don't want to leak it! It seems safe however. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |In Discussion CC| |dcook@prosentient.com.au, | |martin.renvoize@ptfs-europe | |.com, tomascohen@gmail.com -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #16 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #15)
Only to share what I had in mind. It fixes the problem it seems, but can eventually introduce new ones...
Now the session's id is stored in userenv, so we don't want to leak it! It seems safe however.
Yeah, interesting. But in terms of security perhaps not the way we want to go.. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |m.de.rooy@rijksmuseum.nl |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |ASSIGNED --- Comment #17 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Will try to submit another proposal. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Fridolin Somers <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #18 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 172685 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=172685&action=edit Bug 37041: Add C4::Auth::check_value_builder_caller Test plan: Run t/db_dependent/FrameworkPlugin.t Run xt/find-missing-auth_checks.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #19 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 172686 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=172686&action=edit Bug 37041: Use check_value_builder_caller in value builder plugins Test plan: Verify if item editor and tools/batchmod work as expected. Directly hit a value builder plugin like: https://YOUR_STAFF_SERVER/cgi-bin/koha/cataloguing/value_builder/barcode.pl Verify that you get a 403 page regardless of being logged in or not. Run t/db_dependent/FrameworkPlugin.t Run xt/find-missing-auth_checks.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #20 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Counter proposal. Not finished yet, but to give an idea. Check caller stack. Optional exit via new Auth subroutine. Remove check_cookie_auth from value builder plugins. Adjust missing checks script. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #172685|0 |1 is obsolete| | Attachment #172686|0 |1 is obsolete| | --- Comment #21 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 172694 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=172694&action=edit Bug 37041: Add C4::Auth::check_value_builder_caller Test plan: Run t/db_dependent/FrameworkPlugin.t Run xt/find-missing-auth_checks.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #22 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 172695 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=172695&action=edit Bug 37041: Use check_value_builder_caller in two value builder plugins Test plan: Verify if item editor and tools/batchmod work as expected. Directly hit a value builder plugin like: https://YOUR_STAFF_SERVER/cgi-bin/koha/cataloguing/value_builder/barcode.pl Verify that you get a 403 page regardless of being logged in or not. Run t/db_dependent/FrameworkPlugin.t Run xt/find-missing-auth_checks.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #23 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 172696 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=172696&action=edit Bug 37041: Adjust remaining MARC21 value builder plugins Test plan: Edit a biblio record and verify active plugins work as expected. (See first test plan) Test hitting some plugins directly. Run t/db_dependent/FrameworkPlugin.t Run xt/find-missing-auth_checks.t -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #24 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Still needs attention at UNIMARC side -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |In Discussion --- Comment #25 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Marcel de Rooy from comment #16)
(In reply to Jonathan Druart from comment #15)
Only to share what I had in mind. It fixes the problem it seems, but can eventually introduce new ones...
Now the session's id is stored in userenv, so we don't want to leak it! It seems safe however.
Yeah, interesting. But in terms of security perhaps not the way we want to go..
In term of cleaning our session handling code however we need that, and it could be a good excuse to introduce it. If we want it, then do it now. Otherwise we can go with your alternative approach. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #26 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #25)
(In reply to Marcel de Rooy from comment #16)
(In reply to Jonathan Druart from comment #15)
Only to share what I had in mind. It fixes the problem it seems, but can eventually introduce new ones...
Now the session's id is stored in userenv, so we don't want to leak it! It seems safe however.
Yeah, interesting. But in terms of security perhaps not the way we want to go..
In term of cleaning our session handling code however we need that, and it could be a good excuse to introduce it.
If we want it, then do it now. Otherwise we can go with your alternative approach.
Lets separate both developments. I think that the cookie_auth_check should not be in the value builder plugins regardless of the session id being in the context or not. Suppose that the cookie check would pass via context [user logged in with perms], than we still have an unwanted script call resulting in a 500 error. (The original design should have prevented calling those scripts..) So the session_id patches do not resolve the problem of this report. As said before, we could also rely on Apache/nginx etc to restrict access to that folder. But the caller logic is a trivial fix in one place, not affecting the installation itself (apache file etc). So easier to backport? Could we move your patches to a new specific report? What do you think? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff --- Comment #27 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Marcel de Rooy from comment #26)
(In reply to Jonathan Druart from comment #25)
(In reply to Marcel de Rooy from comment #16)
(In reply to Jonathan Druart from comment #15)
Only to share what I had in mind. It fixes the problem it seems, but can eventually introduce new ones...
Now the session's id is stored in userenv, so we don't want to leak it! It seems safe however.
Yeah, interesting. But in terms of security perhaps not the way we want to go..
In term of cleaning our session handling code however we need that, and it could be a good excuse to introduce it.
If we want it, then do it now. Otherwise we can go with your alternative approach.
Lets separate both developments. I think that the cookie_auth_check should not be in the value builder plugins regardless of the session id being in the context or not. Suppose that the cookie check would pass via context [user logged in with perms], than we still have an unwanted script call resulting in a 500 error. (The original design should have prevented calling those scripts..) So the session_id patches do not resolve the problem of this report.
How that? It worked when I've written it.
As said before, we could also rely on Apache/nginx etc to restrict access to that folder. But the caller logic is a trivial fix in one place, not affecting the installation itself (apache file etc). So easier to backport?
Easier but I don't think it is really nice.
Could we move your patches to a new specific report? What do you think?
That will be yet another thing that will get lost. I am willing to abandon it. Obsoleting the patches now. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #171931|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #171932|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #172694|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #172694|1 |0 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #28 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #27)
How that? It worked when I've written it.
Please explain. Those scripts return a hash with builder and launcher. No HTTP for a browser. What probably worked, was calling without being logged in.
Easier but I don't think it is really nice. Agreed
That will be yet another thing that will get lost. I am willing to abandon it. Obsoleting the patches now.
Not my intention. But lacking the time now to follow-up on them too. There was a reason to implement this approach? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #29 from Jonathan Druart <jonathan.druart@gmail.com> --- With the session's id available in userenv you don't have to rely on CGI. And with CGI you get the session's id from the cookie which may be obsolete (example here if you are in the middle/after of a login operation). I am not sure what you want me to explain as I am sure you understood all that already. I just thought it was a good opportunity to clean up this area, as the way we handle the session's id lead us to problem like this one. We should certainly try to reach this workflow: - Auth from credential or CGISESSID cookie - Set userenv - Rely on userenv to know if the user is currently authenticated - Add CGISESSID to the response And the value_builder scripts here would return 403 unless C4::Auth::is_authenticated({catalogue => 1}) is_auth would just need to get the patron's id from userenv, if exists it means that the user is authenticated already. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #30 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Jonathan Druart from comment #29)
is_auth would just need to get the patron's id from userenv, if exists it means that the user is authenticated already.
Wait, isn't that true already actually? Cannot we simply replace the check_cookie_auth call with C4::Auth::haspermission(C4::Context->userenv->{id}, {catalogue => 1}) here? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #31 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #30)
(In reply to Jonathan Druart from comment #29)
is_auth would just need to get the patron's id from userenv, if exists it means that the user is authenticated already.
Wait, isn't that true already actually?
Cannot we simply replace the check_cookie_auth call with C4::Auth::haspermission(C4::Context->userenv->{id}, {catalogue => 1}) here?
No, if this is a direct call to a value builder, the answer should be 403 (or 400) in any case. Not depending on login or permissions. This is what check_value_builder_caller implements too. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion --- Comment #32 from Jonathan Druart <jonathan.druart@gmail.com> --- I think we need to restore the first version, and store the session's id in userenv -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=36934 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #33 from Jonathan Druart <jonathan.druart@gmail.com> --- I have a similar bug, but on.... all pages. It's not directly related to this bug report, but noting it here. diff --git a/Koha/Token.pm b/Koha/Token.pm index 4a806b0e371..150c74e69e5 100644 --- a/Koha/Token.pm +++ b/Koha/Token.pm @@ -130,7 +130,11 @@ sub generate_csrf { my ( $self, $params ) = @_; return if !$params->{session_id}; $params = _add_default_csrf_params( $params ); - return $self->generate({ %$params, type => 'CSRF' }); + warn "GEN"; + use Data::Printer colored => 1; warn p $params; + my $token = $self->generate({ %$params, type => 'CSRF' }); + warn $token; + return $token; } =head2 generate_jwt @@ -181,6 +185,8 @@ sub check { sub check_csrf { my ( $self, $params ) = @_; return if !$params->{session_id}; + warn "CHECK"; + use Data::Printer colored => 1; warn p $params; $params = _add_default_csrf_params( $params ); my $c = $self->check({ %$params, type => 'CSRF' }); Hit the mainpage session table and cookie have 9abb01d0bceff507f39bdb0f1de11cb0 GEN { id "anonymous_9abb01d0bceff507f39bdb0f1de11cb0", secret "X03MO1qnZdYdgyfeuILPmQ", session_id "9abb01d0bceff507f39bdb0f1de11cb0" (dualvar: 9) } 41e446085fd0cb1caa56510a83ba699cd94abe81,2ee4a96fd95b06120f683e38f32c749eb5584b2c,1735765447 fill login form in, submit CHECK { session_id "25d62876954877dc50dad7548e3707bb" (dualvar: 25), token "41e446085fd0cb1caa56510a83ba699cd94abe81,2ee4a96fd95b06120f683e38f32c749eb5584b2c,1735765447" (dualvar: Inf) } wrong_csrf_token GEN # New token is generated with another session id as we display again the login form { id "anonymous_8e19eed358a168c842d0f1642cc21e52", secret "X03MO1qnZdYdgyfeuILPmQ", session_id "8e19eed358a168c842d0f1642cc21e52" (dualvar: 8e+19) } 3cce1ca26137eb16f04489553adeccd0519a38aa,a1e17bfd4720d2e38a37c04cfb5a9a92c8fd4a3f,1735765498 Session table has 8e19eed358a168c842d0f1642cc21e52 9abb01d0bceff507f39bdb0f1de11cb0 Where is coming from the session's ID from the CHECK??25d62876954877dc50dad7548e3707bb Cleared all the data from browser's storage, same problem. Open a private window fixes the problem. I don't have time right now to investigate it more. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #34 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Jonathan Druart from comment #33)
I have a similar bug, but on.... all pages.
It's not directly related to this bug report, but noting it here.
diff --git a/Koha/Token.pm b/Koha/Token.pm index 4a806b0e371..150c74e69e5 100644 --- a/Koha/Token.pm +++ b/Koha/Token.pm @@ -130,7 +130,11 @@ sub generate_csrf { my ( $self, $params ) = @_; return if !$params->{session_id}; $params = _add_default_csrf_params( $params ); - return $self->generate({ %$params, type => 'CSRF' }); + warn "GEN"; + use Data::Printer colored => 1; warn p $params; + my $token = $self->generate({ %$params, type => 'CSRF' }); + warn $token; + return $token; }
=head2 generate_jwt @@ -181,6 +185,8 @@ sub check { sub check_csrf { my ( $self, $params ) = @_; return if !$params->{session_id}; + warn "CHECK"; + use Data::Printer colored => 1; warn p $params; $params = _add_default_csrf_params( $params ); my $c = $self->check({ %$params, type => 'CSRF' });
Hit the mainpage
session table and cookie have 9abb01d0bceff507f39bdb0f1de11cb0 GEN { id "anonymous_9abb01d0bceff507f39bdb0f1de11cb0", secret "X03MO1qnZdYdgyfeuILPmQ", session_id "9abb01d0bceff507f39bdb0f1de11cb0" (dualvar: 9) } 41e446085fd0cb1caa56510a83ba699cd94abe81, 2ee4a96fd95b06120f683e38f32c749eb5584b2c,1735765447
fill login form in, submit
CHECK { session_id "25d62876954877dc50dad7548e3707bb" (dualvar: 25), token "41e446085fd0cb1caa56510a83ba699cd94abe81, 2ee4a96fd95b06120f683e38f32c749eb5584b2c,1735765447" (dualvar: Inf) } wrong_csrf_token
GEN # New token is generated with another session id as we display again the login form { id "anonymous_8e19eed358a168c842d0f1642cc21e52", secret "X03MO1qnZdYdgyfeuILPmQ", session_id "8e19eed358a168c842d0f1642cc21e52" (dualvar: 8e+19) }
3cce1ca26137eb16f04489553adeccd0519a38aa, a1e17bfd4720d2e38a37c04cfb5a9a92c8fd4a3f,1735765498
Session table has 8e19eed358a168c842d0f1642cc21e52 9abb01d0bceff507f39bdb0f1de11cb0
Where is coming from the session's ID from the CHECK??25d62876954877dc50dad7548e3707bb
Cleared all the data from browser's storage, same problem.
Open a private window fixes the problem.
I don't have time right now to investigate it more.
For an unknown reason I had the request header's cookie set to "Cookie: CGISESSID=4a076c38dbe04901e90ef270f88b6a53; CGISESSID=25d62876954877dc50dad7548e3707bb" The second value didn't appear in Storage > Cookie I had to remove the cookies from the browser's settings. There is certainly a bug in our code, or at least we should catch this problem. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #35 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #34)
For an unknown reason I had the request header's cookie set to "Cookie: CGISESSID=4a076c38dbe04901e90ef270f88b6a53; CGISESSID=25d62876954877dc50dad7548e3707bb" The second value didn't appear in Storage > Cookie
I had to remove the cookies from the browser's settings.
There is certainly a bug in our code, or at least we should catch this problem.
Is this in existing Koha code or just these patches? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #36 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to David Cook from comment #35)
(In reply to Jonathan Druart from comment #34)
For an unknown reason I had the request header's cookie set to "Cookie: CGISESSID=4a076c38dbe04901e90ef270f88b6a53; CGISESSID=25d62876954877dc50dad7548e3707bb" The second value didn't appear in Storage > Cookie
I had to remove the cookies from the browser's settings.
There is certainly a bug in our code, or at least we should catch this problem.
Is this in existing Koha code or just these patches?
Current main. Sorry I have put those comments here but it's not directly related to the original bug and the proposed solutions. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #37 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #36)
Current main.
Sorry I have put those comments here but it's not directly related to the original bug and the proposed solutions.
Yikes. Yeah, if you can reproduce it, open up a bug report and CC me in. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #38 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to David Cook from comment #37)
(In reply to Jonathan Druart from comment #36)
Current main.
Sorry I have put those comments here but it's not directly related to the original bug and the proposed solutions.
Yikes. Yeah, if you can reproduce it, open up a bug report and CC me in.
Please add the bug number in See also ? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #39 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- What about pragmatically moving the current patches further while waiting for the better solution which will probably take much longer time ? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff --- Comment #40 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Marcel de Rooy from comment #39)
What about pragmatically moving the current patches further while waiting for the better solution which will probably take much longer time ?
Yes, if you think doing the wrong thing is the way to go, but without me. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #41 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #40)
(In reply to Marcel de Rooy from comment #39)
What about pragmatically moving the current patches further while waiting for the better solution which will probably take much longer time ?
Yes, if you think doing the wrong thing is the way to go, but without me.
There is no good answer to give on that :) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|m.de.rooy@rijksmuseum.nl |koha-bugs@lists.koha-commun | |ity.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #172694|0 |1 is obsolete| | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #172695|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #172696|0 |1 is obsolete| | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #42 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- I removed those patches. I would suggest to open a new report for your solution. And link that one to the problem reported here. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |ASSIGNED -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CONFIRMED -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #43 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Note: I am seeing those errors each week in our production logs. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #44 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- 23.11 Fresh arnings: [2025/03/31 09:44:39] [WARN] ERROR: Plugin marc21_orgcode.pl: ARRAY(0x5653ca19da60) at /usr/share/koha/Koha/UI/Form/Builder/Biblio.pm line 222. [2025/03/31 09:44:39] [WARN] ERROR: Plugin marc21_field_005.pl: ARRAY(0x5653ca09c630) at /usr/share/koha/Koha/UI/Form/Builder/Biblio.pm line 222. [2025/03/31 09:44:40] [WARN] ERROR: Plugin upload.pl: ARRAY(0x5653c56965a0) at /usr/share/koha/Koha/UI/Form/Builder/Biblio.pm line 222. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #45 from Jonathan Druart <jonathan.druart@gmail.com> --- (In reply to Marcel de Rooy from comment #44)
23.11 Fresh arnings: [2025/03/31 09:44:39] [WARN] ERROR: Plugin marc21_orgcode.pl: ARRAY(0x5653ca19da60) at /usr/share/koha/Koha/UI/Form/Builder/Biblio.pm line 222. [2025/03/31 09:44:39] [WARN] ERROR: Plugin marc21_field_005.pl: ARRAY(0x5653ca09c630) at /usr/share/koha/Koha/UI/Form/Builder/Biblio.pm line 222. [2025/03/31 09:44:40] [WARN] ERROR: Plugin upload.pl: ARRAY(0x5653c56965a0) at /usr/share/koha/Koha/UI/Form/Builder/Biblio.pm line 222.
Can you Dump the error? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #46 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #45)
(In reply to Marcel de Rooy from comment #44)
23.11 Fresh arnings: [2025/03/31 09:44:39] [WARN] ERROR: Plugin marc21_orgcode.pl: ARRAY(0x5653ca19da60) at /usr/share/koha/Koha/UI/Form/Builder/Biblio.pm line 222. [2025/03/31 09:44:39] [WARN] ERROR: Plugin marc21_field_005.pl: ARRAY(0x5653ca09c630) at /usr/share/koha/Koha/UI/Form/Builder/Biblio.pm line 222. [2025/03/31 09:44:40] [WARN] ERROR: Plugin upload.pl: ARRAY(0x5653c56965a0) at /usr/share/koha/Koha/UI/Form/Builder/Biblio.pm line 222.
Can you Dump the error?
See above comments. Simply reproduce by logging in on addbiblio.pl URL. Additem is fine too :) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Bug 37041 depends on bug 24879, which changed state. Bug 24879 Summary: Add missing authentication checks https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24879 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to oldoldoldstable |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Logging into addbiblio.pl |Logging into addbiblio.pl |triggers a 403 |or additem.pl triggers a | |403 --- Comment #47 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Just keeping the wish for a solution alive. Here are the additem variants for the same error: [WARN] ERROR: Plugin barcode.pl: ARRAY(0x55ce7d4a92a8) at /usr/share/koha/Koha/UI/Form/Builder/Item.pm line 342. [WARN] ERROR: Plugin dateaccessioned.pl: ARRAY(0x55ce763d0d90) at /usr/share/koha/Koha/UI/Form/Builder/Item.pm line 342. Line numbers from 23.11 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #48 from David Cook <dcook@prosentient.com.au> --- Yeah, this one is always hanging out in the back of my mind... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #49 from Jonathan Druart <jonathan.druart@gmail.com> --- I can follow-up on the "Store session_id in userenv" patches if we agree on the idea. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #50 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #49)
I can follow-up on the "Store session_id in userenv" patches if we agree on the idea.
I can't recall all the details but I think that sounds good. The session_id is part of the userenv imho. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #51 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #49)
I can follow-up on the "Store session_id in userenv" patches if we agree on the idea.
You are welcome too. But I am still not sure if that should be split from this specific bug. Shouldnt we here in the valuebuilder scripts not redirect to login instead of sending 403? This normally occurs when someone tries to login on addbiblio or additem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #52 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Marcel de Rooy from comment #51)
(In reply to Jonathan Druart from comment #49)
I can follow-up on the "Store session_id in userenv" patches if we agree on the idea.
You are welcome too. But I am still not sure if that should be split from this specific bug. Shouldnt we here in the valuebuilder scripts not redirect to login instead of sending 403? This normally occurs when someone tries to login on addbiblio or additem.
Throw an exception. Catch it and redirect? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Jonathan Druart <jonathan.druart@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=40943 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #53 from Jonathan Druart <jonathan.druart@gmail.com> --- My two patches have been moved to bug 40943. I do confirm that they fix the issue with addiblio Bug 40943: Store session_id in userenv Bug 40943: Use session_id from userenv instead of cookie for value_builder -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #54 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #53)
My two patches have been moved to bug 40943. I do confirm that they fix the issue with addiblio
Bug 40943: Store session_id in userenv Bug 40943: Use session_id from userenv instead of cookie for value_builder
Signed them off. Will add something here on top. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|koha-bugs@lists.koha-commun |m.de.rooy@rijksmuseum.nl |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #55 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Marcel de Rooy from comment #54)
(In reply to Jonathan Druart from comment #53)
My two patches have been moved to bug 40943. I do confirm that they fix the issue with addiblio
Bug 40943: Store session_id in userenv Bug 40943: Use session_id from userenv instead of cookie for value_builder
Signed them off. Will add something here on top.
Actually, the original bug has been addressed now. So I will add a new check on a new report. Closing this one. *** This bug has been marked as a duplicate of bug 40943 *** -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=40993 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 --- Comment #56 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- See bug 40993. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041 Andrii Nugged <nugged@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=42494 -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org