Idle Session Timeout

system · February 4, 2013, 12:39pm

zhhealthcare wrote on Monday, February 04, 2013:

Hi,
“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?

Eldho
ZH Healthcare

system · February 4, 2013, 3:45pm

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).

Rod
www.sunsetsystems.com

system · February 4, 2013, 5:50pm

yehster wrote on Monday, February 04, 2013:

Rod,
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.

system · February 4, 2013, 5:56pm

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.

Rod
www.sunsetsystems.com

system · February 4, 2013, 6:27pm

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 auth.inc 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.

system · February 4, 2013, 6:53pm

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.

Rod
www.sunsetsystems.com

juggernautsei · March 30, 2021, 6:58pm

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 auth.inc is the other participant in this session timing.

Suggestions??

sjpadgett · March 30, 2021, 7:07pm

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)

juggernautsei · March 30, 2021, 9:32pm

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.

sjpadgett · March 30, 2021, 9:50pm

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

juggernautsei · April 9, 2021, 10:57am

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.

@brady.miller
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.

stephenwaite · April 9, 2021, 11:54am

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

juggernautsei · April 9, 2021, 12:12pm

@stephenwaite
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.

------PHP 7.4.3

stephenwaite · April 9, 2021, 12:18pm

hah, ok, and what version php?

juggernautsei · April 9, 2021, 1:50pm

Does anyone know the purpose of this

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

stephenwaite · April 9, 2021, 2:22pm

github.com

openemr/openemr/blob/master/interface/main/tabs/main.php#L38-L60


// this will not allow copy/paste of the link to this main.php page or a refresh of this main.php page
//  (default behavior, however, this behavior can be turned off in the prevent_browser_refresh global)
if ($GLOBALS['prevent_browser_refresh'] > 1) {
    unset($_SESSION['token_main_php']);
}


$esignApi = new Api();
?>
<!DOCTYPE html>
<html>
<head>
    <title><?php echo text($openemr_name); ?></title>


    <script>
        // This is to prevent users from losing data by refreshing or backing out of OpenEMR.
        //  (default behavior, however, this behavior can be turned off in the prevent_browser_refresh global)
        <?php if ($GLOBALS['prevent_browser_refresh'] > 0) { ?>
        window.addEventListener('beforeunload', (event) => {
            if (!timed_out) {
                event.returnValue = <?php echo xlj('Recommend not leaving or refreshing or you may lose data.'); ?>;

This file has been truncated. show original

sjpadgett · April 9, 2021, 2:29pm

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.

sjpadgett · April 9, 2021, 2:34pm

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.

juggernautsei · April 9, 2021, 2:49pm

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

stephenwaite · April 9, 2021, 3:21pm

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