https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43847 Bug ID: 43847 Summary: SessionRestrictionByIP: Session cookie not properly shared between opac and backend when using a proxy Initiative type: --- Sponsorship --- status: Product: Koha Version: 24.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs@lists.koha-community.org Reporter: cornelius.hertfelder@bsz-bw.de QA Contact: martin.renvoize@openfifth.co.uk CC: dpavlin@rot13.org Target Milestone: --- Hello, we observes a strange bug when using Anubis as anti-crawler measure and running Kohas backend on port 8080 as default. Anubis (port 443) RequestHeader set X-Forwarded-Proto "https" RequestHeader set X-Forwarded-Port "443" RequestHeader set X-Forwarded-Host expr=%{HTTP_HOST} RequestHeader set X-Forwarded-For expr=%{REMOTE_ADDR} RequestHeader set X-Real-Ip expr=%{REMOTE_ADDR} Koha (port 80) RemoteIPHeader X-Forwarded-For RemoteIPInternalProxy 127.0.0.1 Intranet / backend is directly accessible without proxy (Port 8080). the backend is protected by firewall so we don't need Anubis here. Before we used Anubis the following worked for years: 1. Login to backend 2. go to opac 3. see you're logged in in the OPAC as well. 4. still logged in into backend Now the behavior is as folows 1. Log in to backend 2. go to OPAC 3. not logged in in OPAC 4. Being immediatelly logged out of backend This is caused by the CGISESSID cookie not transfered in the initial request to Anubis / Koha. A workaround is to disable the SessionRestrictionByIP. This leads us to the trusted proxies. Koha should trust the reverse proxies IP and then use the X-Forwarded-For header instead of REMOTE_ADDR. Then, the OPAC behind Anubis should see the same IP as the backend which is directly accessible. We further investigated this but setting trusted_proxies to 127.0.0.1 does not change the behavior. Same same for setting up a botpolicy which will automatically allow clients without challenge. The requests are then still proxies and this causes the problem. I guess there is something missing and some code still uses remote IP. Or trusted proxies is implemented in a way that enforces the X-Forwarded-For header for the backend, too, which is not available here. Hope this will be an easy pick. Cornelius -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.