Is there a way to stop a login on a second tab?

[Andrew Mao]

I'm trying to brainstorm a way to prevent a Meteor app from logging in on a second tab while already opened on the first tab.

The obvious way to do this would be to use validateLoginAttempt to reject the resume login of the second tab. However, when this happens, the second tab assumes the login token is invalid, and deletes it from the browser's local storage. This causes the first tab to log itself out.

Is there any way to stop the second tab from logging in while keeping the first tab logged in?

[Abigail Watson]

I use a different browser or Chrome's incognito mode when I need to test reactivity, but need to be in different parts of the app.  

[Andrew Mao]

I'm aware of how to open up different user sessions. I'm not trying to test reactivity; I'm actually trying to stop users from opening up multiple tabs at once.

[Sam Hatoum]

Not tried this, but I'm brainstorming with you! 

Perhaps you could track Meteor.default_connection._lastSessionId along with a timestamp (for timeout). Put both these values in the user object itself, and when a new tab is opened, see if you have a new lastSessionId and you're within a timeout threshold then don't allow them to login. You may have to keep "pulsing" the timeout to keep a tab alive.

I'm intrigued why you want to do this

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Arunoda Susiripala]

With DDP heartbeats I think session may keep alive. When the session disconnecting remove it from the user object.

You can directly add this overriding some of the Meteor's Session methods. You can easily override Session with my expose package or you might be able to get if from some other ways.

---

Arunoda Susiripala

I curate Meteor Weekly - Check it out!

[Andrew Mao]

Checking for already-logged-in tabs is not an issue with https://github.com/mizzao/meteor-user-status (my package.)

The issue is that rejecting a login causes the tab to delete the local resume token, which then in turn causes other tabs to log themselves out. So you can't just stop one tab from logging in. Your comment did pique one idea though - I can probably just do a Meteor.disconnect() immediately after the login, and then just display an error message.

I'm writing some code for doing behavioral user experiments (https://github.com/HarvardEconCS/turkserver-meteor) and I need to instrument a user's client in specific ways. Having multiple tabs open makes that way harder.

[Abigail Watson]

Have you tried a preventDefault() to prevent the rejecting of login from deleting the local resume token?

Also, I've had some success in using IronRouter to flex the page rendered on a per-tab basis.  With error pages, responsive design pages, and the like.  Is the issue that you truly don't want the login?  Or you simply don't want the user to access the application?  It may be easier to allow the login, but to render anything but the initial tab as an error page, or a page with study instructions (i.e. "please close the browser and use the first browser").  

[Shawn Lim]

Or perhaps you can try logging out the user on all other connected clients. That way the user can only log in at one tab

Meteor.logoutOtherClients([callback])Client

Log out other clients logged in as the current user, but does not log out the client that calls this function.

Arguments

callback Function

Optional callback. Called with no arguments on success, or with a single Errorargument on failure.

For example, when called in a user's browser, connections in that browser remain logged in, but any other browsers or DDP clients logged in as that user will be logged out.

[Andrew Mao]

Abigail: I don't think preventDefault() handles anything other than browser events. The localStorage watcher will probably still see the token deleted and log itself out. Your other suggestion was basically what I mentioned above.

Shawn: That's interesting, but (1) I don't know if it works across tabs because it probably does it by resume token, which is shared in browsers unless localStorage is disabled and (2) even if it works, it's kind of clunky to try to use the 2nd tab's login to trigger a RPC call on the 1st tab, etc.

[Emily Stark]

Hey Andrew,

You're right that Meteor.logoutOtherClients won't log out other tabs because they all share the same resume token.

I'll throw one more idea into the mix which might or might not be useful: if you call `Accounts._isolateLoginTokenForTest()` on the client, then it'll store the login token in a randomly named localStorage key, so each tab will use its own, and logging out one tab with validateLoginAttempt won't interfere with another. But the big downside then is that every page load will use a different localStorage key, so if the user refreshes the page on the one tab in which they are logged in, they'll then be logged out on that tab.

Emily

--

[Sam Hatoum]

You could get around the refresh problem with a param in the URL. When present, do something

[Serkan Durusoy]

If SEO is a concern, URL params that are used for state (or anything other than routing information for that matter) would quickly turn out to be a headache.

[Sam Hatoum]

2 or less params is considered fine for SEO. I agree however, above that is a headache.