Pass login type to client side Accounts.onLogin callbacks #9512
Conversation
Client side `Accounts.onLogin` callbacks are triggered after a successful login, but they're also triggered after a successful DDP reconnect (if already logged in). As discussed in #5127, some people think this is the correct behaviour, while others feel that `onLogin` callbacks should really only fire after a user has actually logged in (e.g. after using something like `Meteor.loginWithPassword`). Since people are split on the proper approach here, an alternative solution would be to provide client side `Accounts.onLogin` callbacks with a way to tell if they're being called after a login or after a reconnect, then let them decide what to do. Server side `Accounts.onLogin` callbacks receive an object that contains various login details. One of those items is a login `type`, that can hold values like `password`, `resume`, etc. When a user completes a true password based login, the returned login `type` is `password`. When the user is already logged in but undergoes a DDP disconnect + reconnect, the returned login `type` is `resume`. This means server side `Accounts.onLogin` callbacks have a way to tell which type of login is happening, allowing them to respond accordingly. This PR adjusts client side `Accounts.onLogin` callbacks such that they also receive a single login details object, that contains login type information. Unlike the server side login details object, the client side login details object only contains the login type (to help reduce network transfer overhead, make sure we're not exposing server details on the client we shouldn't be, etc.). This approach should give developers a better way to respond to different client side login types, and act accordingly. Fixes #5127.
|
LGTM! |
|
Published as |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Client side
Accounts.onLogincallbacks are triggered after a successful login, but they're also triggered after a successful DDP reconnect (if already logged in). As discussed in #5127, some people think this is the correct behaviour, while others feel thatonLogincallbacks should really only fire after a user has actually logged in (e.g. after using something likeMeteor.loginWithPassword). Since people are split on the proper approach here, an alternative solution would be to provide client sideAccounts.onLogincallbacks with a way to tell if they're being called after a login or after a reconnect, then let them decide what to do.Server side
Accounts.onLogincallbacks receive an object that contains various login details. One of those items is a logintype, that can hold values likepassword,resume, etc. When a user completes a true password based login, the returned logintypeispassword. When the user is already logged in but undergoes a DDP disconnect + reconnect, the returned logintypeisresume. This means server sideAccounts.onLogincallbacks have a way to tell which type of login is happening, allowing them to respond accordingly.This PR adjusts client side
Accounts.onLogincallbacks such that they also receive a single login details object, that contains login type information. Unlike the server side login details object, the client side login details object only contains the login type (to help reduce network transfer overhead, make sure we're not exposing server details on the client we shouldn't be, etc.).This approach should give developers a better way to respond to different client side login types, and act accordingly.
Fixes #5127.