[7397] onLogout should provide connection information

[Ragsboss]

Fix for #7397. See commit description for more details. Added a new test and ran all existing tests.
@abernix could you please review this?

[benjamn]

I would just call callback({ userId, connection }) here, to provide a defensive copy of the context information to each callback.

[Ragsboss]

Will do.

[abernix]

@Ragsboss In addition to the comments above, how do you feel about having the onLogin receiving the same parameter (logoutContext) for consistency between the two going forward?

[Ragsboss]

@abernix changing onLogin's current argument would be a breaking change. I'm not sure if this is ok? In fact (as I mentioned in my commit message for first commit), I was wondering if I should instead pass logoutContext as { user, connection } instead of { userId, connection } to make it consistent with existing context (aka attempt in the code) that's passed to onLogin callbacks. As I think more this makes more sense (saving on one user load is too much of a micro optimization and not worth the inconsistency imo). So I changed the code to pass user instead of userId. Take a look and let me know what you think. For reference the onLogin callback receives an object like this based on my tests.
{"type":"password","allowed":true,"methodName":"login","methodArguments":[{"user":{"username":"admin@abc.com"},"password":{"digest":"d6b5d69d3c396de3ffb35077d0bbee33b4605eb9cabf251af305716e61","algorithm":"sha-256"}}],"user":{"_id":"QoxkdfReN8RpnfBKD","createdAt":"2016-07-16T00:34:47.179Z","services":{"password":{"bcrypt":"$2a$10$tRPe0c40CI7c/1MfK9a9fePXQYvHGmr8sh88q/ZGYMAAl3ACLBWve"},"resume":{"loginTokens":[]}},"username":"admin@abc.com","profile":{"firstname":"Admin"}},"connection":{"id":"mr2SQXqQyWeoHMuyi","clientAddress":"127.0.0.1","httpHeaders":{"referer":"https://192.168.56.103/","x-forwarded-for":"127.0.0.1","x-real-ip":"192.168.56.1","x-forwarded-proto":"http","host":"192.168.56.103","user-agent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36","accept-language":"en-US,en;q=0.8"}}}

[abernix]

You're right, we wouldn't want that to be a breaking change. I was mainly rooting for getting the connection and user parameters to be the same – which you've done. I think the resolution of userId to user to achieve this consistency is certainly worth it. Once this is merged, meteor/docs#66 should cover the documentation for this (if you want to take a look).

LGTM.

[Ragsboss]

@benjamn and @abernix thank you for your review and comments. I'm not sure what the process is now. Who can merge this pull request to meteor/devel?

[abernix]

Magical pull-request gnomes will come through and make sure we're all thinking clearly. Give it some time, but they will come. 🍪

(In seriousness, it will be reviewed by the core team in due time – generally within a week)

[mitar]

Are we sure we want to always make a database query here? Why wouldn't we just pass userId and leave to the developer to fetch the user document if they want? I think this is not necessary to do automatically.

[mitar]

(Moreover, you are fetching the user object with all fields, which can potentially be large.)

[Ragsboss]

This is to be consistent with other handlers like onLogin.

[mitar]

I do not see user to be passed to onLogin? connection is cheap, because it is already available. But user object is not.

[Ragsboss]

onLogin does get an object with user property. See following code. This is also mentioned in the documentation and we indeed use this property in our project.

var user;
if (result.userId)
user = this.users.findOne(result.userId);

var attempt = {
type: result.type || "unknown",
allowed: !! (result.userId && !result.error),
methodName: methodName,
methodArguments: _.toArray(methodArgs)
};
if (result.error)
attempt.error = result.error;
if (user)
attempt.user = user;

[tmeasday]

Great work @Ragsboss!