Skip to content
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

Need an event handler / way to check when the user logs in #598

Closed
Tarang opened this issue Jan 9, 2013 · 2 comments
Closed

Need an event handler / way to check when the user logs in #598

Tarang opened this issue Jan 9, 2013 · 2 comments

Comments

@Tarang
Copy link
Contributor

Tarang commented Jan 9, 2013

Persuant to http://stackoverflow.com/questions/14224796/meteor-accounts-framework-signed-logged-in-event

The issue is hacky solutions need to be found for when the user logs in/or out.

E.g when using the accounts-ui, when the user logs in an event to redirect the page (via meteorite meteor-router package) to the correct content.

However if the url is copy pasted to another browser window the accounts page will load (because meteor.autorun is used to run on the page load, as well as when the reactive Meteor.userId changes.

@n1mmy
Copy link
Contributor

n1mmy commented Jan 16, 2013

Thanks for bringing this up, @Tarangp, this is a good point. Users who use the raw login APIs (loginWithPassword, etc) can do this using the callback argument, but users who use accounts-ui have no good way to specify an action to take on login completion. We should add either an event or hook of some sort that fires whenever the user logs in or out, or perhaps some additional options to accounts-ui.

In the mean time, I think a viable workaround is something like:

var oldUserId = undefined;

Meteor.autorun(function() {
  var newUserId = Meteor.userId();
  if (oldUserId === null && newUserId) {
    console.log('The user logged in');
  } else if (newUserId === null && oldUserId) {
    console.log('The user logged out');
  } 
  oldUserId = Meteor.userId();
});

@glasser
Copy link
Contributor

glasser commented Apr 19, 2014

We do not use GitHub to track feature requests (other than for Blaze). The core team's current roadmap is at https://roadmap.meteor.com/. Discussions about features that users desire are great topics for the meteor-talk mailing list, where the community can help come up with solutions that don't require core changes.

Fortunately, there's a workaround as defined above.

@glasser glasser closed this as completed Apr 19, 2014
StorytellerCZ pushed a commit that referenced this issue Oct 1, 2021
In the testing section of the guide (amongst others), the guide references the Meteor "Todos" app: https://github.com/meteor/todos

Previously, `factory` was a locally forked Meteor package within the Todos repo which was a fork of `dburles:factory` with (minimal) tweaks.  See discussion in:

* meteor/todos#193
* meteor/todos#96

With the landing of meteor/todos#202, the Todos application now utilizes `dburles:factory`.  This commit gives the same treatment as that PR provided to `meteor/todos` (https://github.com/meteor/todos/pull/202/files).

Closes meteor/guide#576
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants