lindleycb/meteor-stale-session

Stale session and session timeout handling for meteorjs

meteor-stale-session's Issues

Router hooks fire on heartbeat

Cool package, super easy setup. A lot of my router hooks have Meteor.user checks, and updating the Meteor.user collection causes them to fire. This would probably be resolved if the inactivity was tracked in a seperate collection object other than Meteor.user.

Just a thought. Was a problem for me, but if MDG ends up creating a non-reactive internal router option then I suppose this won't be a problem. I can probably redefine some route rules so this isn't such an issue for me. Nice package though!

Do you have a test that I can run and prove that it works?

It would be good to have an automated test for this

staleSessionInactivityTimeout and staleSessionForceLogout not working

I currently have the following flags set in my app's .json file. Even with staleSessionInactivityTimeout set to ~30 days and staleSessionForceLogout set to false, I notice that about every couple of days I am automatically logged out. What's the logic behind that?

Note I am using Chrome 54.0.2840.100 (64-bit) with default cache settings. I also have multiple AWS instances running different versions of my app (all sharing the same user db). So switching between instances is seamless since I only have to login once.

Note: I do notice that after switching between instances that under Chrome at Chrome -> Settings -> Advanced Settings -> Content Settings -> Cookies -> All cookies and site data -> <my_app> -> Local Storage changes upon every instance switch. Maybe that's related (e.g. session cookie)?

"public" : {
"env" : "prd",
"staleSessionInactivityTimeout" : 2628000000,
"staleSessionHeartbeatInterval" : 180000,
"staleSessionPurgeInterval" : 60000,
"staleSessionActivityEvents" : "mousemove click keydown",
"staleSessionForceLogout" : false
}

Thanks!

Enhancement: Client-side redirecting to a login page when timeout is hit

I'm testing the use of this package (which seems to be just what my security group wants us to have - thanks!) but when the session is purged from the server the client doesn't seem to know about it and allows the user to continue using the app until it makes a call to the server to do something and then most of the time it just appears to hang (at least to a user). I was thinking about enhancing the client.js so that it kept track of the last activity and when the client hit the timeout threshold it redirected the browser to the login page. I know this could be overridden by js on the client, but I don't care about playing nice with hackers, but for regular users when the timeout was hit they would be back at the login page. An additional enhancement might be to put up a warning a minute or two before to prompt them to do something so the timeout is extended.
Thoughts?
thanks,
stephen

Heartbeat issue

If a user logs in and closes the browser before the heartbeat interval has elapsed they never get a heartbeat registered and thus never get logged out. I've fixed this for now by calling heartbeat in an onLogin callback, but I'm kind of thinking this is something the package should take care of. I was also wondering if it might be better to use debounce on the event handler rather than a setInterval.

I can do a pull request when I get some spare time, just wanted to put this out there for now in case anyone else runs into this.

Only logout client if really inactive (currently also logs him out if he's just offline)

Could you please help me wrapping my head around the following scenarios?

1. A user is using my meteor-application for some time, switching his device off for a while. He should be asked to log in again.
2. A user is using my meteor-application and looses the network connection for a while. He's still actively working with the data on the screen. Once he connects back, he should remain logged in.

Is there a possibility where I can inform the server that the client has been active in the meanwhile, before he kicks him out? I thought about calling Meteor.logout() if this.userId is set, but activityDetected is not, in https://github.com/lindleycb/meteor-stale-session/blob/master/client.js#L20. Do you think this would be a good approach? Another option would be if you call the heartbeat method with a timestamp. Then you could ensure that the next timestamp needs to be heartbeatInterval away from the last (with some margin). Since the system now saves the requests if the connection is down and tries to resend as soon as it's available, this could work ... what do you think?

Standard Meteor Accounts package sign out button in loginButtons template stops working

After adding this package to an app, the regular Meteor Accounts package loginButtons template still shows the Sign out button, but clicking it has no effect. No errors are shown in the console. The dropbown menu closes, but that's all.

Meteor version is 1.2.0.2

Has anyone seen this before and resolved it?

detecting activity on touch screen mobile device - comparable to mouse movement?

On a desktop, this package will detect mouse movement... is there any way to detect similar activity on a mobile device, ie, finger swipes of the page?... If a user is active, but not clicking buttons that cause meteor activity, It is timing out, but the same thing on a desktop would have mouse movement and thus would not time out...

Update "as it currently stands"

In the README:

As it currently stands, (meteor 0.6.6.3)

Hooking on to the session timeout

Hi guys,

I love the package, it is really simple to use and lightweight.

Just one thing that I have been unable to do, is hook on to the timer interval being set at startup.
I would like to add a notification countdown modal to display time left until automatic log out, however we are overwriting the Meteor.logout() method and I had hoped that Stale Session was using it but unfortunately that approach has failed.

Is there any way to latch on to Stale Session to create such a countdown display (ie. "30 seconds left")

Thank you and kind regards,
Chris

staleSessionInactivityTimeout ramdomly not working once in a while

in Meteor.startup(function () { …

i have added Accounts.validateLoginAttempt(function(attempt) { …

with a console.log( attempt.type …

it result the unattended reconnect is of type “resume”

this occur ramdomly once in a while

as it is a major security concern i wonder how other people do ? 🚑

i'm not alone to find that bug see https://forums.meteor.com/t/47412

thx

Allow disabling for a user

If an application wants to allow users to disable this on a per-user basis it's currently not possible. Something like this would be helpful

meteorStaleSession.disableForUser(userId);

which could update the user document with a property that signals not to include them in the auto logout interval, so this query could be updated from

Meteor.users.update({heartbeat: {$lt: overdueTimestamp}},
                            {$set: {'services.resume.loginTokens': []},
                             $unset: {heartbeat:1}},
                            {multi: true});

to something like this

Meteor.users.update({heartbeat: {$lt: overdueTimestamp}, staleSession: { enabled: { $eq: true }}},
                            {$set: {'services.resume.loginTokens': []},
                             $unset: {heartbeat:1}},
                            {multi: true});

Configuring to log off after browser close

Thanks for this session management plugin, I was looking to see if there is a way to always log the user off if they close the current browser and to terminate all their sessions ?

Doesn't work if my publications are referencing this.userId

This package was working great for me until I added this:

  if (!this.userId) {
    console.log("subscribing without being logged in, from: " + this.connection.clientAddress + " denied!");
    return;
  }

to the top of my Meteor.publish function.

Once I added these lines (as a security check so that you coudn't subscribe to publications when logged out)... it seems that when I get to a stale session state, the websocket is severed, but my app still functions, but it can't get to the server any more... I suppose I'll have to put this code into a demo to explain better... but hoping you might know off hand what the issue is.

In the Network tab of the inspector in Chrome, I see a second websocket show up once the session "times out" ie. becomes stale. But the app doesn't show that I'm logged out.

But, without the check for this.userId in the publish, it does work fine, and the user is shown the login screen and they are "logged out" of the app automatically.