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.