Autologout triggered in background tab, no indication in other open tabs

Confirming this issue as it has bit us in production. Adjusted issue title and description a bit with more detail.

Looking at this.

I tried to reproduce this with the steps provided without any luck. I tried with the default settings and also with the enforcement on the admin pages. If you are still able to reproduce this, can you please share the settings for your site?

@AjitS I updated the steps to reproduce and notes about real-world use case. I think the key is that attention is drawn away from multiple open tabs and the logout only takes place in one tab, not all of them. I just followed the steps again and it triggers the scenario.

Able to reproduce, looking into this.

Will trigger logout in all tabs if the "Enforce auto logout on admin pages" configuration option is checked, otherwise will only trigger logout in all non-admin tabs.

Yeah, this is a huge problem for us. During presentations, showing the client how great the new site is, because one of the tabs I was working in or demoing from earlier times out, the one I'm working in times out as well.

Hello,

I tested this locally and it did not work. I have updated the solution. The current implementation will keep the connection alive while the tab is in the background.

Please let me know if something is off.

Thanks.

@ngkoutsaik - I'm not sure how to pull a version of the module that includes your commits from today. I'd love to be able to try it out, as I've needed to disable autologout due to the background logout issue.

Hi Steven,

at the top of the page, there is a 'Show Commands' button. Clicking on it shows a couple of commands you can copy and paste to pull the code I pushed.

If you got the module using composer you will have to download it using git first. You can find more instructions here.

Let me know if something is not clear.

@ngkoutsaik thank you for this patch!

The latest patch on this ticket fixed the bug for me when you have multiple tabs open and using autologout 1.4 or the latest dev.
This is an issue on most modern browsers when you have multiple tabs open.

My testing:
- Set the timeout to 60 seconds.
- Open the homepage in a new tab.
- Open a node edit form in a new tab. The node edit form should have at least 1 CKEditor enabled field - example: Body.
- Stay on the node edit form tab and do not move your mouse for 1 - 2 minutes.

RESULTS:
Expected: You are not logged out on any of the open tabs since you are on a node edit form.
- Autologout 1.4: BUG - You are logged out on the inactive tab with the homepage.
- Autologout 1.4 with the patch for this ticket 3214958: Meets expectations - You are not logged out on the homepage tab.
- Autologout 1.3: Meets expectations - You are not logged out on the homepage tab.

Regression from 1.3: The 1.4 release introduced a new request parameter "uactive" that tracks whether the user is active or not. This fails when the browser tab is inactive - It falsely thinks that the user is still on the inactive tab and not doing anything, therefore, it logs you out.

Scenario I'm experiencing:

1. Open tabs A, B, C in the same Drupal site (admin pages)
2. Keep focus on tab A, inactive until Autologout triggers
3. Click to reset in tab A, also navigate to tab B and click to reset, but do not navigate to tab C (keeping that tab inactive)
4. Continue work in tab A
5. Autologout time will run out in Tab C and logs user out of the entire site

Desired behavior should be to click for reset in any 1 tab to keep the user logged in the site. Reset in one tab should override/cancel the autologin triggers in all other tabs. It doesn't seem practical to have the user address every instance of autologout trigger in multiple tabs.

@ctsiokos I was not able to reproduce your issue. Can you provide a bit more info on it? Using the code provided on the branch I pushed, this should not happen.

The reset not working is related to the cookies. At this point when the code tries to update the cookie, an error occurs. Then the timeout hits and you are logged out.

I will create a ticket for that.

@ngkoutsaik

Set Timeout value in seconds to 120
Set Timeout padding to 60
Get a timer

Try and follow these steps as close to the time indicated as possible. It's important to only make the clicks necessary below:

• 0:00 Start a logged in session on Tab 1, Use a link(internal to your site) from Tab one to open Tab 2. (Accumulated time: Tab1 (:00) Tab2 (:00) )
• 0:30 Click something in tab 2 to reset the session time (Accumulated time: Tab1 (:30) Tab2 (:00) )
• 1:00 You should be prompted to reset the session in tab 1, reset it. I did not get a reset message in my last active Tab 2 (Accumulated time: Tab1 (:00) Tab 2 (:30) )
• 1:30 You should be prompted to reset the session in Tab 2, even though you reset it in Tab 1 30 seconds ago. Do nothing on either Tab you, you just reset your session in Tab 1 30 seconds ago so you have 90 seconds until you timeout if it were working properly (Accumulated time: Tab1 (:30) Tab 2 (:60) )
• 2:30 You were probably just logged out in tab 1 but should have had 30 seconds left to renew the session (Accumulated time: Tab1 (1:30) Tab 2 (2:00) )
• 3:00 You'll get booted again on Tab 2 but it's irrelevant at this point.

Thank you so much for your work on this issue; it's been a long-standing pain point for editors of a site that I'm maintaining.

It's coming along really nicely; I wanted to report an issue where multiple prompts are appearing. I produced this by:
- Opening two node edit forms
- Allowing the timeout to expire (in my case, two mins) on one of them until I saw the prompt
- Reset it (I had to click twice/there were two modals stacked onto eachother)
- Click the tab with the other node edit form, allow the timeout to expire
- Click to reset again and observe multiple prompts

@ngkoutsaik

Thanks for looking into it. I'm still experiencing the same scenario, (The patch works!) I'm not sure what to add. It seems to me the module is working on a page-level/local instead of domain-level/server. The logic shouldn't be "I want to extend my login on this page, but not on this other page".

I can confirm that this merge request works, but doesn't this create a security issue the module is designed to prevent? If someone is on a public computer, logged into Drupal, opens a new tab and does a bit of browsing.. then forgets about the open tab and walks away... a half hour later, someone can come along, open the background Drupal tab, and still be logged in. Or am I misunderstanding what the patch does? What about using local storage, so the tabs all have a common source they can check to see if the session has been extended?

@mkinnune

The patch in #22 works well for me! I'm seeing the prompt in the tab I have open which works better, and only need to close it once.

I've rebased this issue fork on the 8.x-1.x branch to resolve the $.cookie is not a function issue (https://www.drupal.org/project/autologout/issues/3195008).

I've heavily tested the issue fork and can confirm that the autologout session reset prompt is only triggered in the active tab. The issue of a content editor not seeing the session reset prompt and getting access denied once submitting a piece of content has (mostly) been resolved.

However, when the 'Enforce autologout on admin pages' setting is disabled, there are a couple of behaviors that might not be desired:
- When you have non-admin and admin tabs open, and you refresh an admin tab and keep it open, autologout will never be triggered. While I personally like this behavior, it could be an unintended change.
- Relatedly, when you have non-admin and admin tabs open, and you refresh an admin tab, but then visit a non-admin tab, autologout will start getting triggered, even when you visit an admin tab again.

Additionally, I have also noticed two issues:
- (This seems to occur only with the 'Enforce autologout on admin pages' setting disabled, but I did not heavily test it with it enabled.) When you have a non-admin tab open in one window, and an (active) admin tab open in another window, autologout will get triggered in the inactive window/tab, and the user will get logged out without receiving the prompt. This is not as much of an issue if the windows are open on separate displays/next to each other, however, if the non-admin tab window is open below the admin tab window, it is. This does not occur when the non-admin tab window is minimized.
- Lastly, the biggest issue I noticed is that when you're browsing other websites in other tabs (for example while I'm writing this comment), autologout is never triggered.

Just tested the patch from the 3873c593 - Simplify condition commit - same result as before. One tab , non-admin, was logged out. Others, one admin, one node edit and one home page was left as is.

I'm not good with JavaScript so can't tell for sure how it was working or what is currently proposed, but suggestions in #20makes perfect sense to me - local storage or a cookie , either should work in my understanding, most important part here is single source of truth for all tabs. Equally all tabs should react on the condition to log out and do something, e.g. show modal or log out.

Since I'm unable to open a new merge request (gets stuck on "Checking if merge request can be merged..."), I'm uploading the alternate approach using settings.activity from the seemingly related/duplicate #3319047: Autologout does not consider activity while creating node and adding content on ckeditor of paragraph. And autlogout manager getRmaining time is having improper code to fetch logout_regardless_of_activity data.

The patch should resolve the original issue while also avoiding the issues described in comments #17 and #24.

@gombi The patch in 26 works much better. It keeps all of the tabs logged in if the user selects to stay logged in on whichever tab they have open. It also still logs the user out if they are focused on a tab that is not open to the Drupal site and they exceed the time limit, which is kind of the point of the module, so that's good.
The only issue that I think could confuse users (which isn't a very big issue and I don't think it should keep this from being merged) is that the modal stays up on the background tabs even once you've selected to stay logged in on the tab you have open.

Thank you, the #26 patch is working. Looking at the original source, I think the issue maybe caused by:

From ajaxGetRemainingTime() in file src/Controller/AutologoutController.php:

    if (isset($active) && $active === "false") {
      $response->addCommand(new ReplaceCommand('#timer', 0));
      $response->addCommand(new SettingsCommand(['time' => 0]));

      return $response;
    }

Just wanted to understand the logic of this module.
Does anyone know why we are not updating the JS timer based on the $_SESSION/$_COOKIE,
but the line above will logout all browser tabs immediately, regardless of activities of other tabs.
Could this be the root cause of the issue we are having?

Is it possible to disable this so user will lost everything once the time is gone?

edit: I just realized there is option : Logout user regardless of activity already. So ignore my post.

I have applied patch #26 but I am still facing this issue. Is there any update on this?

Tested the code form MR (which is the same as in patch) and it works. Changed the code to use request stack instead of the global php session and cookie.
If I have multiple tabs open and on the last active one I am logged out (either by the pop up window or without it) I am also logged out from other tabs. If I have the pop up enabled and I trigger the "keep me logged in" via clicking the yes button, I am also not logged out from other tabs.

@pankajsachdeva Can you provide more information on what is not working for you?

Also the code from here is basically the same as in the #3319047: Autologout does not consider activity while creating node and adding content on ckeditor of paragraph. And autlogout manager getRmaining time is having improper code to fetch logout_regardless_of_activity data as mentioned in the comment #26. It seems this one is a little bit more active, but for the maintinaers to give credit also on that issue, it needs to stay open.

This issue also confirms the issue with the setting of the logout time to one minute as it's not working (you are always logged out after 2 minutes). But that is handled in #3307938: Undetected request prevents logout which will need to be updated once this is merged as there are some changes in the JS file.

And the test for migration are failing because of a core issue #3192893: [META] Serialization issues in Migration tests.

RTBC. The failing errors are handled by different issues, that do not relate to problems with this fix.

This is still an issue when you have disabled "Enforce auto logout on admin pages" - meaning if a user is on an admin page, then they should not be logged out.

It seems like the new activity tracking (1.4+) does not properly consider the "refresh only" mode to keep you logged in.
See https://www.drupal.org/project/autologout/issues/3395581#comment-15525827
and https://www.drupal.org/project/autologout/issues/3395581#comment-15526740