bradymiller wrote on Thursday, August 04, 2011:
yehster,
Are you saying you may have a per script way to deal with the sessions stuff?
-brady
yehster wrote on Thursday, August 04, 2011:
Brady,
Yes, I believe that if we add
window.onbeforeunload=top.restoreSession;
To any script that either uses links or form submits to get to the next page, it will handle the session info correctly. This will work if the submission to the server is happening in the same frame.
I’m not sure how it will work if one frame is changing another frame, (like in this case with the encounters drop down) I haven’t tested that scenario.
We might be able to include the call in a shared file somewhere and have it address the potential that onSubmit and onClick functions are missing the appropriate call almost everywhere.
This won’t handle sessions with ajax calls correctly, for that we should probably use
http://api.jquery.com/ajaxStart/
We’d have to check the sequence of events to be sure, but if EVERY script had onbeforeunload it might have caught this particular bug with the encounters drop down, and I do mean every.
Another possibility is adding the event to each frameset in “/interface/main/main_screen.php”
Rod or anyone else, Is there any drawback to calling top.sessionRestore() too many times that I might be missing?
bradymiller wrote on Thursday, August 04, 2011:
Hi,
I believe you can’t cause any harm by overusing top.sessionREstore() function. Rod, can you confirm this. It would be very nice to have a global solution here. (I was gonna add this as an additional step in the Security walk through, but looks like it my not be needed). For the shared file, could it be placed in the script that holds the sessionRestore function itself??
-brady
yehster wrote on Thursday, August 04, 2011:
I certainly understand that calling top.rs() too many times would slow down the browser if it got excessive, but if it got called 2-3 times instead of just once, would it really matter?
I don’t think it can work in restoreSession.php.
what we would need is
“window.onbeforeunload=top.restoreSession()”
to be included in the scripts section of every page.
The best candidate I see right now is to put it in library/js/common.js
Anyway, I’m fairly certain that if for any new scripts, if one where to add window.onbeforeload=top.sessionRestore() to a script element, you wouldn’t have to worry about explicitly setting onclick for every link and form submit.
w.r.t. “security walkthrough” were you talking about testing for one login/session effecting another?
sunsetsystems wrote on Thursday, August 04, 2011:
It’s OK to call top.restoreSession() mutiple times. But I’m not a fan of putting in code that has no utility at all, as it adds to the mental clutter when a developer is trying to understand a script. Would prefer to see it done or not on a case-by-case basis and not arbitrarily for all scripts.
Suggest also testing with Opera.
yehster wrote on Thursday, August 04, 2011:
Didn’t test with opera as it is documented that onbeforeunload is not supported.
The intent isn’t to randomly litter the scripts, but to find a single place or a consistent method for a call that handles most of the potential hazards if a developer fails to manage the session appropriately. It certainly wouldn’t be code with “no utility”. Like a vaccination of sorts, might not be 100% effective, but I’m hoping it prevents a lot of mistakes.
sunsetsystems wrote on Thursday, August 04, 2011:
Would onunload work just as well? Just thinking about Opera support. OK the “vaccination” philosophy makes sense… just be sure to document the code accordingly so someone coming along later will get it.
mike-h30 wrote on Wednesday, August 17, 2011:
The user that reported the problem is also experiencing this issue? Is this related?
When I log out of EMR my screen always goes white and says at the top “Site ID is missing from session data!”
Mike
bradymiller wrote on Tuesday, August 30, 2011:
Hi Yehster,
Just checking if you’re still working on this. Would be nice to get it into the 4.1 release, if so.
thanks,
-brady
yehster wrote on Wednesday, August 31, 2011:
Brady,
I don’t think there is a solution that works that won’t “touch” a whole lot of files, so I think it makes sense to wait until after the 4.1 release to try and get this working.
-Kevin
bradymiller wrote on Thursday, September 01, 2011:
Hi Kevin,
Sounds good.
thanks,
-brady