https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42494 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- I thought OpenFifth already worked on this one. Hmm... what version? -- 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=42494 --- Comment #3 from Andrii Nugged <nugged@gmail.com> --- Created attachment 198332 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=198332&action=edit Bug 42494: Preserve staff login cookies for plugin responses Logging in directly through plugins/run.pl can authenticate the current request but fail to persist the new staff session in the browser. run.pl calls get_template_and_user, which creates or replaces the CGISESSID and returns the Set-Cookie header that must be sent with the response. Normal staff scripts pass that cookie to output_html_with_http_headers. Plugin requests delegate rendering to Koha::Plugins::Handler, and plugin methods may print responses through Koha::Plugins::Base helpers, so the cookie returned by get_template_and_user is not carried to that response path. The visible result is that a user can submit credentials on a plugin page once, but reloading the same plugin page prompts for login again. Logging in through mainpage.pl first avoids the problem because the browser already has a valid staff session cookie. This patch passes the staff login cookies from plugins/run.pl through Koha::Plugins::Handler to the plugin instance, then uses them as the default cookies for Koha::Plugins::Base response helpers and plugin home redirects. Explicit cookies passed by plugin code are still honoured. This applies to the shared plugin response helper path rather than to any single plugin or plugin method. Security note: This patch does not create or validate sessions itself. Session creation, replacement, and authentication remain in get_template_and_user/checkauth; this change only preserves the Set-Cookie values returned by that layer until the plugin response is printed. The outgoing staff login cookies are stored on the plugin object until the response helper is called. Perl does not make that private, so a plugin could technically inspect them. This does not change Koha's existing plugin trust model: installed plugins are already trusted server-side Perl code. Please review the authentication-cookie implications carefully. Plugins that bypass Koha::Plugins::Base and print raw headers remain responsible for their own response headers. The regression test covers Handler::run with plugin HTML output and verifies that the CGISESSID Set-Cookie header is emitted along with the plugin response. Test plan: 1. Apply patch. 2. Open a plugin URL in a browser without an existing staff session. 3. Log in from the plugin page. 4. Reload the same plugin URL and confirm it stays logged in instead of showing the login form again. 5. Log in through /cgi-bin/koha/mainpage.pl and confirm the plugin page still works with the normal staff session. 6. Run: prove -I. -It/lib t/db_dependent/Koha/Plugins/Plugins.t 7. Run: prove -I. -It/lib t/db_dependent/Auth.t -- 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=42494 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- Thanks for providing a patch. That saves me a lot of time. I'll take a more in depth look later (it's already 5:31pm here), but I've taken a quick glance and it's looking pretty good at a glance. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.