Do you use or administer OpenEMR? Take the General Satisfaction Survey to help improve the product

Idle Session Timeout

zhhealthcare wrote on Monday, February 04, 2013:

“Idle Session Timeout Seconds” is calculated using the user activity at the server side. So even if a user is inputting data in a form, but not submitting the page before the “timeout” settings the user will get timed out and lose all the data he entered. Can we capture some key events at the browser and send to the server intermittently, which prevents the server from session out? This is a problem for the practices which prefer to keep the timeout seconds very low , say 15 minutes.
Can this create any security threat?

ZH Healthcare

sunsetsystems wrote on Monday, February 04, 2013:

I think that would be a good thing to do.  But I wouldn’t add yet another server request, but rather add the logic to one that already exists (see for example interface/main/daemon_frame.php).


yehster wrote on Monday, February 04, 2013:

I must be missing something, but your suggestion doesn’t make any sense to me.  There is logic in the timeout mechanism which explicitly prevents the daemon frame from resetting the timer.  I don’t see how daemon_frame is relevant.

sunsetsystems wrote on Monday, February 04, 2013:

Kevin, read my suggestion again.  I’m saying that daemon_frame.php is a good place to add appropriate logic,  I.e. that it’s better to modify an existing module that periodically invokes the server than it is to create a yet another one.


yehster wrote on Monday, February 04, 2013:

Rod, I know that we disagree on how best to handle cross frame communication, so before we fall too deep into that rat hole again.  Here is my last comment on this topic.

Eldho,  feel free to follow Rod’s suggestion, but my instinct is that if you try to do it with daemon_frame.php, you are also going to have to make changes in as well and the overall solution is going to be more difficult to maintain.  It will also be very difficult to get daemon_frame to respond to keypress events that occur in the other frames.  Daemon frame generates a periodic event (every 2 minutes) , but the keypress events you wish to trigger on do not occur periodically.  They happen at a pace that is determined by the user actions.

sunsetsystems wrote on Monday, February 04, 2013:

Of course there will be code changes.  Difficult???  All it requires is a logical approach, to be determined.

Keypress handing is another topic.  What makes sense to me is to have a JavaScript variable in the top frame (or perhaps the left_nav frame) that is set when a keypress occurs.  Then daemon_frame (or something else that already communicates periodically with the server) can check that and do the right thing when it’s set.

I don’t think it’s right to ping the server on every key press.  So doing it periodically makes sense.  Doing it periodically with yet another new module for that purpose does NOT make sense.

This is not to defend daemon_frame.  If someone wants to replace it with something else, fine, let’s discuss it.  But in a different thread please.


Although this topic is 8 years old. It is happening again within v6.0.
I am getting a lot of reports of the system timing out no matter what the globals are set to. I thought I would open an investigation into the SessionTracker.php file and how it is used in the system. I notice that the is the other participant in this session timing.


We’re missing a restoreSession() somewhere important.
I’d look at any new ajax/fetch in forms or older scripts recently touched.
Maybe accumulate reports of where this mostly happens.
I always suspect reminders or workflow were folks have multi patients opened in new tabs or user agent(browser)

1 Like

Ok, I will start the hunt for the missing restore.
I always ask about the multi browser instance thing but it happens to me and I have four different browsers.

It’s not the browser but maintaining the session across open tabs/windows under the same user agent(chrome, FF etc).

1 Like

What tool can I use to track sessions? It seems to be very random as to when the session gets broken.

I have read the restoreSession.php file notes. That only tells me how it works. It does not tell me how to fix or find the issue. As @sjpadgett pointed out, there has to be a missing restore session. That is the needle in the haystack.

We need to talk about this on tomorrow’s tech call. I am getting a lot of requests to fix this soon.

Can we change the behavior of the system to not just time out and break workflow but have a warning system?

Also, is there a way to have the code checker look for where the restore session should be in all ajax calls?

It seems next to impossible to find where the break is occurring since there are no clues to track down the issue.

hi @juggernautsei, any more details like when and where this happens?

the time out is really random. One time, I was on the calendar and selected week view. Then, selected a day of the week from the top of the calendar and the session id was lost. I tried it again and it did not happen.

So, it is really random. There seems like a gremlin in the system.

image ------PHP 7.4.3

hah, ok, and what version php?

Does anyone know the purpose of this

Why is this needed and says to use at your own risk?

This is used to prevent or allow reloading openemr from browser reload url button. When testing I turn off.
There isn’t anything dynamic here so, look elsewhere unless users are using reload then maybe could effect session refresh.

btw: I’ve tested having three patient up in one browser tabs and one other in same user agent browser window.
Ran um all day(large value in timer) while occasionally doing encounters in each etc.

No issues. So I’m a little befuddled however, something has changed because on timeout, no landing page.

1 Like

Really I just wanted know why that was there. It is new to me. I had not seen it till today.
Thanks @sjpadgett

after opening a pt in new window and playing around in demo can see a repetitive csrf error in the demo log

like there’s something in background_services.php that won’t give up the ghost

Screenshot from 2021-04-09 11-22-19