Problem/Motivation
On the settings page (/admin/config/people/autologout) there is an "Enforce auto logout on admin pages" option to include administration pages for automatic logout.
But it is not clear which paths or areas are included, and what exactly "admin pages" means ...
Original wording of issue:
Automated Logout is not logging me out
I set a short time out for testing purposes. Automated logout is not logging me out after a period of inactivity.
Steps to reproduce
1. Go to simplytest.me
2. In the project field, enter autologout
3. Select Automated Logout from the drop-down menu
4. Set the version number to 2.x-dev
5. Create the site
6. Login as admin
7. Click Extend
8. In the search field, type auto
9. Expand Automated Logout item
10. Click Configure
11. Set the three seconds fields to 60, 120, 60 respectively (one minute default, two minutes max, one minute grace period)
12. Save the configuration
13. Click Content
14. Click Add content
15. Click Basic page
16. Type a title
17. Type some body text
18. Wait for a minute
Expected result: I get the dialog letting me know that it's going to log me out soon for inactivity. I have a minute to respond to it.
Actual result: Nothing happens. Actually, it's been about 5 to 10 minutes now while I fill out this issue, and it still hasn't logged me out.
Proposed resolution
We could improve the documentation for the "Enforce auto logout on admin pages" feature, by re-wording the help text below this option.
Remaining tasks
Create a text which better conveys the behaviour when "Enforce auto logout on admin pages" is enabled.
User interface changes
The "Enforce auto logout on admin pages" help text is updated.
API changes
Data model changes
Issue fork autologout-3579880
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3579880-automated-logout-is
changes, plain diff MR !99
- 8.x-1.x
changes, plain diff MR !98
Comments
Comment #2
the_g_bomb commentedCan you try going to Configuration > Automated logout settings
Then in the config form, could you tick the checkbox:
"Enforce auto logout on admin pages"
This should mean the logout settings will affect those on the admin routes as well.
Comment #3
the_g_bomb commentedComment #5
vinodhini.e commentedHi, Tested on Drupal 11.2.3. After enabling the option “Enforce auto logout on admin pages”, users were logged out correctly on admin routes. Working as expected. Thanks.
Comment #6
the_g_bomb commentedGreat news, thanks for letting us know.
Comment #8
charles belov@the_g_bomb:
That's not what I would have expected from the wording of that setting. While I was logged in as an admin, I was not on a
/admin/path, I was on a/node/path.From the wording, I would expect this to only apply to pages on the
/admin/path, not simply be logged in as admin. I would have thought that the Role timeout setting would be used to protect the admin from timing out under any circumstances.I recognize that a logged in user could have multiple tabs open, and that I would expect to not be logged out without this checked if I had any of my browser tabs open to a page on the
/admin/path. However, that was not the case here; I only had a single browser tab open, and it was open to a/node/page.Because of this current behavior, there is no way to set that an admin is to not be logged out if they are on an
/admin/page but be logged out if they are on a/node/page. Although I admit I would be far more nervous about leaving a/admin/page exposed then a/node/page.Comment #9
the_g_bomb commentedSorry, there is a bit of "Drupalisms" at play here.
By admin routes, I did mean /admin/* pages, but I recognise now that that doesn't necessarily also obviously lend itself to include the node/*/edit page, but in this case it does. Node edit is an editor function and so is treated as an admin route. (On the /admin/ path, to be accessed by those logged in to the backend and having permissions to configure the site.)
You are correct that this setting does not affect an administrator role or any other user with admin rights.
/node/123 is a front-end page
/node/123/edit is an admin page to be accessed by an editor
/node/add also an admin page
Comment #10
the_g_bomb commentedPerhaps this ticket should become something about the wording of the setting. Happy to take suggestions on how to improve the clarity.
Comment #11
charles belovThank you for the explanation. It's unfortunate that the term admin has been overloaded; I never would have considered simple editing to be an administrative function. I'll open a separate issue for the setting wording to avoid confusion within the current issue.
Comment #12
charles belovActually, I'm having trouble locating documentation of these multiple senses of the term administration. I've posted a comment on the discussion page for the Drupal glossary. I don't feel I can file an issue on the setting wording or whether I would want to reopen this current issue until that comment is resolved, preferably through a glossary update.
Comment #13
the_g_bomb commentedPerhaps just making the label clearer on the config page here would be enough.
https://git.drupalcode.org/project/autologout/-/blob/8.x-1.x/src/Form/Au...
Maybe something like:
Enable autologout on administration pages
With the description
By default, autologout keeps the session alive on administration pages. Enable this to apply autologout there too. This includes content editing pages (such as node/add and node/*/edit) on sites where "Use the administration theme when editing or creating content" is enabled.
Comment #14
charles belovI'm not sure that you were saying this but to be clear, I don't believe that theming would change the nature of a page. If a node edit page is an administration page, then it doesn't matter whether it uses the administration theme or the website theme or some other theme entirely.
Where I'm having trouble is in seeing node edit pages as administration pages. I'd like to see somewhere in Drupal.org documentation where it says that the Drupal community defines administration pages as including node edit pages, because to me, administration pages are pages which are typically reserved for website administrators. Since node edit pages are typically open to all editors, I do not think of them as administration pages.
The proposed wording:
does not get across that concept.
Comment #15
charles belovNo need to respond yet. I've got a lead and am going to do some testing.
Comment #16
charles belovOK I guess it's not the fault of the wording. I've confirmed that Drupal core overloads the term "administration" and needs to educate developers and users of the difference. So it's not a problem of your module specifically. I will pursue that other path and consider the current matter closed. Thank you for the education.
Comment #17
the_g_bomb commentedAs you may have discovered there is work ongoing to improve Drupalisms.
Do you think changing the use of admistration pages, to backend pages
Maybe something like:
"Enable autologout on backend pages"
With the description:
By default, autologout keeps the session alive on backend pages. Enable this to apply autologout there as well. This includes content editing pages (such as node/add and node/*/edit) on sites where "Use the administration theme when editing or creating content" is enabled.
While, I agree that the "administration theme" itself won't change things much, `i msy be wrong, but I think the setting at the bottom of /admin/appearance does change the node/add forms into what are deemed "admin" routes. Unchecking this would mean node/add and node/{nid}/edit pages are not treated as admin routes, which could change the functionality of autologout.
Comment #18
ressaI agree that it can be difficult to describe the behaviour, and also debugging it can take time :)
For easier debugging, I added the "Automated logout info" block to both the regular, as well as the admin theme. Under administration ("back end") pages such as
/admin/config/peopleas well as/node/add/pageand see this message:If under
/admin/config/people/autologout"Enforce auto logout on admin pages - If checked, then users will be automatically logged out when administering the site." is enabled, I now get this message under those paths:I had a look in the code, and found this in
src/AutologoutManager.php:... and looked around for info about
isAdminRoute, and found:I verified that it is still necessary to check "Use the administration theme when editing or creating content" on the theme admin page at
/admin/appearanceif you want to enforce autologout behaviour fromnode/editand/node/add/pagepages.Great suggestions @the_g_bomb, I do think we should perhaps stick to using the "admin page" concept, since it's such an ingrained Drupalism, but add examples of paths? I tweaked your great suggestion a bit, and perhaps the help text could be updated from:
... to something like this?
Comment #22
ressaI created an MR with a suggestion for an updated help text.
PS. I accidentally created it for 1.x-dev first ... perhaps the default branch can be set to 2.x on GitLab? Thanks! https://git.drupalcode.org/project/autologout
Also, perhaps the project page could be updated, to have a short text about the two versions (Version 2 and 1.7) and how (if) they differ here?
Comment #23
ressaComment #24
the_g_bomb commented+1 for the movement of the default branch, unfortunately I don't have permissions to do that.
That being said, I think we should create a 3.x branch to do a major update and drop Drupal 9 and > 10.2.
Once that is out we'll be supporting 1 branch from then onwards.
Comment #25
ressaThanks for a fast reply @the_g_bomb.
Since you are by far the most active member of the project's 13 members (could be the record?) -- and the de facto maintainer of the project -- perhaps you can request getting granted the GitLab "Maintainer"-role from one of the four members with the "Maintainer"-role? https://git.drupalcode.org/project/autologout/-/project_members
Then you are also free to update the project page text, and create a 3.x branch, to facilitate future improvements, which sounds like a great plan by the way.
But all that aside, what do you think about the MR? :)
Comment #26
the_g_bomb commentedI've had a look at the MR, and it looks good.
Two thoughts, I wondered if we should alter the use of "Enforce", as I thought it sounded like it would kick people out straight away. I thought enable might sound like it was just applying the settings there as well. But happy to be talked back on this.
I also wondered if we are putting too much information in the field description now.
Perhaps a halfway house like:
Comment #27
ressaThanks for the feedback, I agree that it got too wordy, and also that using "Enable" is more precise wording, and I updated the MR. Looking forward to hear what you think about the revised MR.
PS. If useful as inspiration, here's a "request Maintainer role" issue from another project: #3556750: Applying for 'Maintainer' role for the project Block Class on Gitlab.
Comment #28
charles belovNoting I've filed #3580372: Stop overloading the term "administration" regarding the Drupalism.
As I commented on the MR, I find the proposed wording very clear (and not leaving me to puzzle out why the behavior).
Comment #29
ressaThanks for starting a discussion in #3580372: Stop overloading the term "administration" (which is now connected to this issue) it's always a good idea to revisit and adjust this kind of jargon, adopted organically over a long period, which may not be precise enough.
Feel free to change the status to "Reviewed and tested by the community" @charles belov.
Comment #30
charles belovComment #32
charles belovHmmm, I'm pretty sure I picked Reviewed & Tested by the Community. Not sure how Closed came up.