https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42494 Bug ID: 42494 Summary: Staff login through plugins/run.pl does not persist the new session cookie Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs@lists.koha-community.org Reporter: nugged@gmail.com QA Contact: testopia@bugs.koha-community.org When a staff user reaches a Koha plugin page directly while unauthenticated, Koha displays the normal staff login form. After submitting valid credentials, the plugin page renders for the current request, but the browser does not keep a usable authenticated staff session for the next request. Reloading the same plugin page asks for login again. If the same staff user first logs in through /cgi-bin/koha/mainpage.pl and then opens the same plugin URL, the plugin page can be reloaded repeatedly as expected. To recreate: 1. Use a staff user with permission to run a plugin tool/report. 2. Clear browser cookies or use a private browser window. 3. Go directly to a plugin run URL, for example: /cgi-bin/koha/plugins/run.pl?class=Koha::Plugin::...&method=tool 4. Submit the staff login form with valid credentials. 5. Confirm that the plugin page renders. 6. Reload the page. 7. Notice that Koha asks for login again. 8. Clear cookies or log out. 9. Log in through /cgi-bin/koha/mainpage.pl with the same staff user. 10. Open the same plugin URL and reload it several times. Actual result: The login through plugins/run.pl only works for the current request. The browser does not appear to receive/persist the new authenticated CGISESSID needed for later requests to the same plugin page. Expected result: Logging in through a plugin URL should persist the staff session in the same way as logging in through mainpage.pl. Technical note: plugins/run.pl calls get_template_and_user and receives the authentication cookie returned by checkauth. When plugins are enabled, run.pl delegates the response to Koha::Plugins::Handler and the plugin usually renders through Koha::Plugins::Base output helpers. That path does not currently carry the cookie returned by get_template_and_user into the plugin response, so the Set-Cookie header can be lost. This is related in spirit to bug 40943 / bug 37041, where code after login had to use the current authenticated session rather than stale request cookie state, but this issue is specific to plugin execution through plugins/run.pl. I will attach a proposed patch. It is intentionally offered for review as a candidate fix: it propagates the authentication cookie returned by get_template_and_user from plugins/run.pl through Koha::Plugins::Handler to the plugin output helpers, so might be not the best solution or have a backhole. Because this touches authentication cookie propagation for plugin responses, please review carefully from both QA and security perspectives. I am not aware of a privilege escalation here; the concern is that the proposed fix changes where Koha includes staff login cookies in plugin-generated responses. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.