From matthew at biospective.com Tue Sep 13 15:31:36 2016 From: matthew at biospective.com (Matthew Lee) Date: Tue, 13 Sep 2016 15:31:36 -0400 Subject: [Loris-dev] Multiple instances on single VM login bug Message-ID: Hi all, I ran into an issue with running multiple instances of LORIS on one VM, and I found a fix, but I need advice. To preface the problem, I should explain how it arose. We want to access LORIS through one main url, but we also want to obscure what projects we're running if a user doesn't need to use that instance. So, if we're running project ABC001, we don't want those users to see we have a project MNI007. We have ended up configuring apache to map different directories to different urls. i.e. /var/www//htdocs maps to loris.biospective.com/ The problem we ran into was that logging on to MNI007 could grant access to ABC001 if they enter the different url. The solution I found was to change the php session save path via ini_set(). What I need advice about is where to set this new save directory. I initially set it to /var/www//user_sessions, but I don't have any attachment to that location. Does anyone have any suggestions or opinions? I can expand on how the different instances are set up if that will help. Thanks, Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.macfarlane2 at mcgill.ca Wed Sep 14 10:37:50 2016 From: david.macfarlane2 at mcgill.ca (Dave MacFarlane) Date: Wed, 14 Sep 2016 10:37:50 -0400 Subject: [Loris-dev] Multiple instances on single VM login bug In-Reply-To: References: Message-ID: Hi Matthew, Even if the cookies are shared between your multiple LORIS instances on a single VM, site-restrictionsshould still be applying based on the logged in user (unless they have the access all sites permission.)Which pages are you finding that they can get around this on? As far as your solution goes, I don't think the filesystem path matters. Your suggestion is as good as any,but perhaps you should consider setting the session.cookie_path variable instead (or in addition to) the session.save_path. It sounds to me like the real problem is that the browser is sending the cookie to instances that it shouldn't(because the cookie is set for the entire domain, but is only supposed to be valid for a sub-path of thatdomain), not the location that that server is saving the sessions on the filesystem. Changing it to saveto a different location fixes the problem incidentally (since the different instances aren't looking up theirsessions in the same place) but doesn't solve the root cause (that the different instances can read cookiesmeant for the other instance with your current configuration.) - Dave From: matthew at biospective.com Date: Tue, 13 Sep 2016 15:31:36 -0400 To: loris-dev at bic.mni.mcgill.ca Subject: [Loris-dev] Multiple instances on single VM login bug Hi all, I ran into an issue with running multiple instances of LORIS on one VM, and I found a fix, but I need advice. To preface the problem, I should explain how it arose. We want to access LORIS through one main url, but we also want to obscure what projects we're running if a user doesn't need to use that instance. So, if we're running project ABC001, we don't want those users to see we have a project MNI007. We have ended up configuring apache to map different directories to different urls. i.e. /var/www//htdocs maps to loris.biospective.com/ The problem we ran into was that logging on to MNI007 could grant access to ABC001 if they enter the different url. The solution I found was to change the php session save path via ini_set(). What I need advice about is where to set this new save directory. I initially set it to /var/www//user_sessions, but I don't have any attachment to that location. Does anyone have any suggestions or opinions? I can expand on how the different instances are set up if that will help. Thanks, Matthew _______________________________________________ Loris-dev mailing list Loris-dev at bic.mni.mcgill.ca http://www.bic.mni.mcgill.ca/mailman/listinfo/loris-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.macfarlane2 at mcgill.ca Wed Sep 14 13:48:35 2016 From: david.macfarlane2 at mcgill.ca (Dave MacFarlane) Date: Wed, 14 Sep 2016 13:48:35 -0400 Subject: [Loris-dev] LORIS v16.1.1 Message-ID: It was recently brought to our attention that LORIS v16.1.0 stopped working after an automaticupdate to Google Chrome that users have no control over. A third party polyfill meant to add supportfor HTML5 date elements to Firefox started causing a javascript error in Chrome after thelatest update. Alex updated the code to use jQuery datepicker if modernizr detects the browser doesn't supportthe date element type. This should be more robust and fix the issue so that users of Chrome will beable to use LORIS again, even if they update their browser. Anyone using v16.1.0 should probably update to v16.1.1 (unless their users exclusively use Firefox.) - Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: