New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[1.5.2.1] Using accounts-* package keep logging out #9140

Closed
ymchun opened this Issue Sep 27, 2017 · 27 comments

Comments

Projects
None yet
@ymchun

ymchun commented Sep 27, 2017

After upgrading to Meteor 1.5.2.1, Meteor session keep logging out after some time (e.g. few minutes). But no problem when rollback to 1.5.2.

I am using ubuntu 16.04 and Angular 2 for the frontend.

List of packages:

  • accounts-base 1.3.2
  • accounts-password 1.4.0
  • alanning:roles 1.2.16
  • angular2-compilers 0.6.6
  • dynamic-import 0.1.1
  • ecmascript 0.8.2
  • email 1.2.3
  • es5-shim 4.6.15
  • jquery 1.11.10
  • meteor-base 1.1.0
  • mobile-experience 1.0.4
  • mongo 1.2.0
  • reactive-var 1.0.11
  • shell-server 0.2.4
  • slam310:smooth-scroll 0.0.5
  • standard-minifier-css 1.3.4
  • standard-minifier-js 2.1.1
  • tracker 1.1.3
  • twbs:bootstrap 3.3.6
@hwillson

This comment has been minimized.

Member

hwillson commented Sep 27, 2017

@ymchun - you might be impacted by #9066, which was fixed and released with 1.5.2.1 (see a549448). Are you by chance setting the Accounts loginExpirationInDays config option to null? If not, would you be able to put together a reproduction? See Reporting a bug in Meteor.

@ymchun

This comment has been minimized.

ymchun commented Sep 27, 2017

@hwillson I didn't set this option, docs said it defaults to 90.
#9066 said session expired after page reload, I didn't reload page but navigate to other view using angular 2 router. Then the session token in localStorage get cleared.

It seems the session not expired when reload page but it just expired after some time.
Explicitly set loginExpirationInDays to 90 not helping.

Using ddp debug, seems after login, the server update the session token which expired immediately.

I will look into it for reproduction.

@spencern

This comment has been minimized.

spencern commented Sep 27, 2017

Seeing this in multiple projects at Reaction after updating to 1.5.2.1

accounts-base@1.3.3
accounts-facebook@1.2.1
accounts-google@1.2.0
accounts-oauth@1.1.15
accounts-password@1.4.0
accounts-twitter@1.3.0

Blaze and React frontend. Don't have time to put together a reproduction immediately, but wanted to chime in.

@maxfi

This comment has been minimized.

maxfi commented Sep 28, 2017

Since upgrading to 1.5.2.1 I'm seeing a whole bunch of the following in Galaxy APM (Kadira) for the login method:

Error message:

[method] Error, too many requests. Please slow down. You must wait 2 seconds before trying again. [too-many-requests]

The app is trying to resume the session:

userId : USER_ID_HERE
params : [{"resume":"TOKEN_HERE"}] 
@ymchun

This comment has been minimized.

ymchun commented Sep 28, 2017

@maxfi Same here using ddp debug

@maxfi

This comment has been minimized.

maxfi commented Sep 28, 2017

@ymchun Did you upgrade from 1.5.1 as well? What is ddp debug?

@ymchun

This comment has been minimized.

ymchun commented Sep 28, 2017

@maxfi My app upgraded from 1.5.2 to 1.5.2.1

and the ddp debug
meteor add deanius:debug-ddp

@maxfi

This comment has been minimized.

maxfi commented Sep 28, 2017

@hwillson From the recommendation in Meteor allow/deny vulnerability disclosure – Meteor Blog I updated from 1.5.1 to 1.5.2.1 and deployed as the app uses most of the packages mentioned in the post.

As this issue has been adversely affecting my users today what is the recommended resolution to this? Should I rollback to 1.5.1? Thanks.

@jamiter

This comment has been minimized.

Contributor

jamiter commented Sep 28, 2017

The big question is, is this an 1.5.2.1 issue, or an issue with the allow-deny package upgrade? If it's the latter, we either have this or a security issue. We are looking into it to see whats the root cause.

Update: as far as we can see now it's unrelated. I'll keep you updated.

@abernix

This comment has been minimized.

Member

abernix commented Sep 28, 2017

@maxfi The recommendation in the article you linked to was to update allow-deny. If you're having additional problems, please simply roll your application back to 1.5.1 and just update allow-deny by running meteor update allow-deny.

@jamiter This cannot be an issue with the allow-deny package. Your help looking into it is much appreciated! It's possible that changes in account-base@1.3.3 are causing issue? Perhaps you could try using Meteor 1.5.1 and pinning allow-deny@1.0.9 (to avoid the security vulnerability) and accounts-base@=1.3.2 (to see you avoid the login problems)? Additionally, if you can confirm that the login problems return with accounts-base@=1.3.3, we can be more sure that its something related to those changes.

@hwillson hwillson self-assigned this Sep 28, 2017

@maxfi

This comment has been minimized.

maxfi commented Sep 28, 2017

@abernix You're right. My bad. I've rolled back to 1.5.1 and updated to allow-deny@1.0.9. I'll report back if there are still issues. Thanks.

@hwillson

This comment has been minimized.

Member

hwillson commented Sep 28, 2017

Hi all - I've found the problem and am working on a fix. More details coming shortly.

@rj-david

This comment has been minimized.

rj-david commented Sep 28, 2017

I've upgraded to 1.5.2.1 and then decided to upgrade my unreleased apps to 1.6.beta.32. I was just logged out twice when testing.

@abernix

This comment has been minimized.

Member

abernix commented Sep 28, 2017

A release candidate for Meteor 1.5.2.2 has been released which includes this change. Please help test it and confirm whether this issue is fixed!

meteor update --release 1.5.2.2-rc.0
@iamkevingreen

This comment has been minimized.

iamkevingreen commented Sep 28, 2017

Testing the new release and still experiencing issues.

Seems like 1.5.2 did finally fix my segfaults but this is equally as painful:

account packages

accounts-base@1.3.4-rc1522.0
accounts-password@1.4.0
alanning:roles@1.2.16
allow-deny@1.0.9
@jamiter

This comment has been minimized.

Contributor

jamiter commented Sep 28, 2017

Great news! I’ll have a look soon!

@tab00

This comment has been minimized.

tab00 commented Sep 29, 2017

I was experiencing this behavior when using version 1.5.2 with loginExpirationInDays: 7. Even though Meteor.loginTokenExpires in the browser local storage showed the correct date, it would just disappear after some minutes and user logged out.

Whilst still on 1.5.2 (because I cannot update due to #9141), after changing to loginExpirationInDays: 3650 the user is no longer logged out after some minutes.

I'm not sure whether my experience is relevant.

@WayneUong

This comment has been minimized.

WayneUong commented Sep 29, 2017

I'm experiencing random logout locally when I make some changes and the browser just logouts and then proceed to hot reload.

@hwillson

This comment has been minimized.

Member

hwillson commented Sep 29, 2017

@WayneUong Are you seeing this behavior after updating to the 1.5.2.2 RC?

meteor update --release 1.5.2.2-rc.0
@MartiniHenry1988

This comment has been minimized.

MartiniHenry1988 commented Sep 29, 2017

It seems to be fixed for me, I am testing my app from past 4 hours, my user is still logged in.

For those who are still looking for a fix, please try:

meteor update --release 1.5.2.2-rc.0

I will continue testing my app, if I found any irregularity in behavior, I will report here

@hwillson

This comment has been minimized.

Member

hwillson commented Sep 29, 2017

@iamkevingreen Just to confirm, you're still seeing users get logged out after running/testing with the 1.5.2.2 RC? Can you describe the problems you're seeing in more detail? The 1.5.2.2 RC seems to fix this issue for others, so any extra details you can provide would be greatly appreciated.

@fermuch

This comment has been minimized.

fermuch commented Sep 29, 2017

After several hours (~6 hours) using 1.5.2.2-rc.0, I can confirm this solves my issue.

@iamkevingreen

This comment has been minimized.

iamkevingreen commented Sep 29, 2017

@hwillson any save on client/server, also updating data in compose (i connect to a remote database if that helps) will also trigger a log out.

I can provide more information if you let me know how you want it provided

node v8.1.2
full list of packages: https://gist.github.com/iamkevingreen/c468c723a6f610d3d2aa695f719c2dd2

@benjamn benjamn closed this in c5f642c Sep 29, 2017

@iamkevingreen

This comment has been minimized.

iamkevingreen commented Oct 4, 2017

After restarting my machine this is no longer an issue for me 👍 (on 1.5.2.2)

@harrisonhunter

This comment has been minimized.

harrisonhunter commented Oct 17, 2017

Sorry if I missed this, but was there any action required to get this fix to work besides updating?

I've tried updating to 1.5.2.2 and to 1.6-rc.13 and I'm still getting similar behavior, staying on 1.5.2 and the accounts packages bundled there works totally fine.

Possibly it's something else / new with the accounts packages but the behavior seems very similar where on hot reload / deployment / sometimes randomly seeming, the connection gets logged out and thus can't load anything until refresh. (timing wise it also lined up with this issue, so assuming it is same)

@raphaelarias

This comment has been minimized.

raphaelarias commented Nov 1, 2017

I'm having the same error. I went directly to 1.6 from 1.5.2.

When we open a new tab, the login is not validated, and I have to login again in the new tab. Which allowed me to login in two different users, in the same browser, at the same time.

Apparently that happens on Chrome not on Firefox em PROD.

@raphaelarias

This comment has been minimized.

raphaelarias commented Nov 3, 2017

PS: I discovered what was happening. On PROD we were being logged out every time we opened a new tab (and only logged out in that tab, we could event login with different users on both).

We used to use appcache but we've uninstalled. It may have left something behind, as soon as we've cleared the Chrome app data, everything went back to normal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment