We have a site that is experiencing some odd behavior.
Periodically throughout the day, they get the dreaded \"Site ID is missing from session data!\" message.
They\'ve also been getting re-directed back to a login prompt occasionally on form submissions.
I also noticed in the apache logs, the session name is getting renamed very frequently. We use a unique session id for this site but it\'s constantly getting set back and forth between the specified session name and \"default\". Today alone, this switch happened 117 times.
I\'m not reaaly sure what\'s going on with this one. These problems manifest randomly and from multiple workstations/users in their office. Tony McCormick asked me to post this here because it sounds like a bug.
They\'re using verson 4.1.0. It\'s an ubuntu-based system with other running clients that don\'t experience this issue. I\'ve done some connection testing between the client site and the server and see nothing that indicates an unstable connection. Granted, while I was doing the tests everything looked fine, but there could be somethining happening intermittently when these other problems appear. Still, I would expect to get page timeout errors instead of the weird/missing session data. I checked session.gc_maxlifetime and it\'s set to 14400 in php.ini so I\'m thinking a simple time out is not the issue.
There are also a few custom modificatons made to the site, but they\'re forms and don\'t interfere with the session.
Thanks for reading.
Not sure what could be causing this but if I were going to try to debug this I'd work on improving the dreaded "Site ID" error message. It should be possible to at least improve it a little, maybe include the session ID in the error message, and also log when a session "expires" from OpenEMR's own timeout mechanism (based on last_update) in auth.inc.
Also in looking at this function in auth.inc. I'm not really sure that the mechanism here for preserving the site_id really works. A global here is global to a single page request, not the application as a whole.
function authCloseSession ()
// Before destroying the session, save its site_id so that the next
// login will default to that same site.
$incoming_site_id = $_SESSION['site_id'];
Sounds like you've got a tricky bug to figure out.. Good Luck.
Perhaps your session.gc_maxlifetime value is too small, causing session data to disappear prematurely. Check that and other session-related configuration in php.ini.
Kevin, $incoming_site_id is set and used within the same request.
I too have been seeing quite a bit of the "Site ID" errors during my testing of 4.1.1 but thought that was due to me dropping my OpenEMR database and importing a backup for testing with various data while leaving the browser open (Chrome) and last OpenEMR login on screen. I'll keep on eye on it.
I'm pretty sure this started, for us, with 4.1.0 upgrade. We did not see this before that at all.
Rod, got it. Didn't look deep enough before to realize that the mechanism there was to hand off from a closing session back to the login screen in the same request.
One scenario that may explain the "Site ID" and might be consistent with the timeline of 4.1.0 upgrade is the dated reminders polling.
The issue is that a session can only be closed once. So here's what might be happening.
1. Login/do stuff
2. Leave your browser idle for time > $timeout
3. dated reminders is polling in the meantime, and when it polls after the timeout has expired the session gets closed.
4. Since dated reminders is doing this as an ajax request, the redirect to the logon screen isn't happening
5. Your session is now invalid, and although your existing frames may be still up in the browser your next request is going to result in "Site ID…" since they are going to try to use a closed session.
My hypothesis is that if polling by the daemon_frame is what triggers an old session to get logged out, you get redirected to the login screen, but if the polling happens because of dated reminders you get "Site ID error…" on your next request. Which one "wins" is going to depend on modulo arithmetic of idle timers/refresh intervals..
Jeremy, one clarification question. Is the issue you are seeing occurring only after an idle period? Or can it happen "spontaneously".
One way to test my hypothesis would be to log the what page is being requested and referring page in authCloseSession().
It would be much better if daemon_frame does all polling for everything that needs it. That was a "master plan" that I failed to advertise. :) It's also more efficient that way.
I personally think that polling by AJAX request that dated reminders uses is a cleaner mechanism than the polling by frame reload mechanism daemon frame uses. But based on our previous disagreement about race condition management I know we have rather different coding standards/styles.
I do agree that a consistent polling mechanism would be in order though.
dated reminders could move into daemon_frame or daemon frame could move into a more generalized ajax mechanism.
Am definitely open to an improved method, as long as it's consistent and works.
I am encountering the "Site ID missing" message as I try to create the "practice" in OpenEMR 4.0. I have migrated from an older OpenEMR 32 used in teaching nurses about EHR's, following all instructions to upgrade as given in the OpenEMR download site. This error is independent on the session time, it shows all the time (i.e., cannot create the "practice".) Any ideas on how to fix this error?
'Jeremy, one clarification question. Is the issue you are seeing occurring only after an idle period? Or can it happen "spontaneously".'
This is happening spontaneously. My session.gc_maxlifetime is set to 14400 (4 hours) and the problem is happening within the amount of time it takes for some doctors to fill out a simple soap form.
Do they have more than one window/tab of OpenEMR up at any given moment?
From your description of seeing SiteID change, it sounds like the SiteID truly is getting changed, and it's not simply a timeout. It's possible that a request is being sent which specifies a blank SiteID in the request parameters thus resetting to "Default".
Also make sure your php.ini is what you think it is. You can create a PHP script that contains only this line:
<?php phpinfo(); ?>
And then run it to find out what the active setting is for gc_maxlifetime, and the location of the php.ini that was loaded.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.