And then in my React Meteor container, I’m passing Session.get('emailResetRequest') into my component and if it’s true, it pops up a dialog to allow the user to input their new password.
I think that’s not hacky, at least setting a local state (Session.set(‘emailResetRequest’, true) and then using the layout to show a reset-password screen, when this state is set.
I did the same, but i ignored the done-callback and it seems to work. Not sure, if it is really needed.
Yeah, I’m not really sure what that callback does. IMO the documentation is unclear: (emphasis mine)
done: A function to call when the password reset UI flow is complete. The normal login process is suspended until this function is called, so that the password for user A can be reset even if user B was logged in.
I’m not really sure what user B has to do with user A resetting their password.
You request a password change for account B (which most interfaces won’t let you do anyway).
Then you open the link yourself (while still logged in on account A) and you enter your new password etc.
When done you are still logged in under account A but the password for B has changed.
Very strange when thinking about it but maybe it has a use-case.
I did the same, but i ignored the done-callback and it seems to work. Not sure, if it is really needed.
That may make sense:
The normal login process is suspended until this function is called
It seems this functionality is somehow related to the login process. I assume that if your are handling this password reset process while https://docs.meteor.com/api/accounts.html#Meteor-loggingIn === true you may encounter some issues but this is all not very likely.
Yeeeeeeeah, I’m not really sure that this “feature” or Meteor adds anything except complexity. But that’s how it was, so I just documented it and made public APIs.
The idea is, let’s say someone borrowed your computer and logged in to their account. Then you open a password reset link. It would be weird if it went to a page where your friend is logged in.
But I think that’s a relatively small edge case. I don’t think this is something we could remove at this point without breaking lots of stuff.
Well, I learned some new stuff here! Accounts.urls appears to be undocumented, but it is in the Meteor Guide. Very cool. I also didn’t know about Meteor.absoluteUrl! Now I can get rid of my Meteor.settings.public.baseUrl.