Issues with Accounts.registerLoginHandler after upgrade to Meteor 3.2

Dear all,

We recently upgraded our platform from Meteor 3.0.4 to the latest 3.2.
We’ve ironed out the few issues related to Express v5 and everything seems to work well except one thing:

We’ve a custom login handler that we use to auto-login users accessing our platform through LTI.
our custom login handler currently returns an object containing “userId” (the id of the user in the DB) and “token” (generated with “Accounts._generateStampedLoginToken()”).

  log.info(`${fn}: Logging user ${account._id} in via LTI connection`);
  await updateUserByIdAsync(account._id, { $set: { "lti.launch.authorization": "logged-in" } });

  // session is valid. confirm login
  return {
    userId: account._id,
    token: Accounts._generateStampedLoginToken()
  };

This code doesn’t seem to work reliably now, after the upgrade… when the custom login handler is executed I see the code being called and returning the object but the client doesn’t seem to receive anything back… the state of the client is with the user being “logging in” (that is, I’ve a Meteor.userId() but with Meteor.user() returning undefined). So we’re stuck in this endless waiting game (never receiving any update) until we reload the page (and then we’re logged in).

This is happening only after our update. If we run this code in Meteor 3.0.4 we don’t have any issue.

Have there been any changes in the way custom login handlers are supposed to work (or, more specifically, in the object they have to return upon successful login)?

We included oauth fixes in Meteor 3.1.1. I wonder if this is related, since those changes also affected client-side code.

Can you check if it still works with Meteor 3.1? Then try upgrading to 3.1.1 and see if the issue appears?

1 Like

Hey @nachocodoner , thanks for the quick feedback, it’s super appreciated!
Fortunately I kept a copy of the entire development tree with version 3.0.4. I’ll try doing what you suggest, upgrading it first to 3.1 and then 3.1.1 and taking note of when the issue appears :crossed_fingers:

Yes, I understand changes to oauth/accounts packages are fragile and hard to reproduce and share. We also lack good test coverage there, since they rely on external services. At some point, we may need tests with mocking.

In any case, if you can share more details here or privately about how your custom login is structured, it might help us reproduce and fix the issue.

1 Like

Funny thing is: I tried doing what you advised and everything kept working just fine, both in 3.1, 3.1.1, 3.1.2 and 3.2!

I guess it was just an inconsistent state of Meteor between runs (in the process I also cleaned up all the cache folders so that might’ve contributed in “fixing” the issue).

So, I’d say it was a false alarm. Apologies for the false flag. I’ll keep testing around this for a bit, but so far it seems to be working correctly :person_shrugging:

Thanks again for jumping on this so promptly!

2 Likes