Hi all.
When using multiple tabs on the same meteor app, I see several connections are created.
This I can tell from using the Accounts.onLogout method on the server, which receives an object with “user” and “connection” props.
This is great and allows me to see the first logout (which comes with the user prop with info in it) and the subsequent logouts from the additional tabs (which come with the user prop unset and the connection prop set, allowing me to verify indeed several connections where made).
Now, Accounts.onLogout doesn’t receive any arguments when used on the client (as per my tests and the documentation).
Is there a way to realize my logout was fired from another tab? (or better: the reason the logout has fired up? For example: It would be great to know if the user has been auto logged out for whatever reason)
Any help will be most appreciated.
Best regards!
When a user logs out actively in your app, i.e. via by pressing a button or selecting a menu item, you could record this action prior to happening in Meteor.Session. Then in Accounts.onLogout on the client you can check that Session var. If there isn’t any, it was an “auto” logout.
Hey! Thanks Peter for the idea! That’d be indeed closer to what I want to get!
Now, say for example I’ve been logged out because of the LoginExpirationInDays configuration, or any other reason. Is there a way I can actually find out this? The why of the log out event? Like in bank apps when they say: “you’ve been inactive for X period of time, so bye”. Or something that could lead the user to understand why and how to prevent such in the future, or any kind of information that would be useful.
I’m not sure I’m aware all of the possible active/inactive logout scenarios, so maybe let’s go through them one by one. The context of checking is of course always in Accounts.onLogout.
-
user has multiple tabs open and they actively log out in one of those. You could document that event on localStorage. In your apps running in all other tabs you’d be able to render a warning message accordingly. Upon Meteor.startup on the client you would probably have to delete that localStorage item.
-
check localStorage.Meteor.loginTokenExpires, parse and determine whether in the past.
-
“you’ve been inactive for X period of time, so bye” scenario. This is potentially tricky in a multi-tab situation, since the user probably won’t be able to stay active in all tabs at the same time. If you want to allow for your users to stay logged in if they’re still active in any of the tabs, you’d need to constantly manage their active status on localStorage. meteor-user-status seems to be an obvious choice for this, but I myself never used this package.
Are there any other scenarios you need to be prepared for?
Well, thanks a lot for a lot of insights.
- That’s great. Got that solved then. I’m guessing either Session storage is different for each tab or there is a specific tab-related value I can save there, right?
- Also great. I didn’t know about that local storage key. So with that I can determine if expiration was the cause of the logout.
- That package Looks promising! I’ll dive into it. Thank you very much. I’ll post here If I found out a solution to this scenario.
- There must be other scenarios in which the server logs you out, that I would like to know about. Actually this question is originated in one client of mine, who is experiencing “random” logouts on multiple tabs scenarios. And thus I wanted to offer more explanation in the ui than merely showing the login page again. Maybe the user status package can help here as well. (I can confirm it is not the loginExpiration in the storage, which has been set to about a month in the future)
Thanks again for the thorough response.
You’re welcome.
That’s right. An each tab there’s an instance of the application, and each has its own Meteor.Session. The tabs of the same app, however, share localStorage, IndexedDB and cookies.
1 Like