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.