https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37041
--- Comment #26 from Marcel de Rooy <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
