Meteor 3: Inconsistency between client and server login status

help
1

I’ve been using Meteor 2.x so far. Since I switched to 3.x, I am noticing a weird behaviour on a page that uses Meteor.call() directly in a useEffect() on page load.

This works fine, if the user is coming from a different page and thus already logged in. However, if I reload the browser window, it happens that the client reports the user as being logged in, but the server method still reports this.userId() or Meteor.userId() as being null. What might cause this behaviour?

I would expect that the DDP connection is the single source of truth for both client and server. How can the client think it’s already logged in, but the server thinks it’s not?

2

How about you depended on being connected. You can try the following to see the condition under which both userId and connected are true so you can call your method. This happens to me a lot and see those unauthorises method calls in the APM. You can also delay the call by 50-100 ms if necessary (after the conditions are true).

useEffect(() => {
   // if both are true, call your method.
    console.log(Meteor.userId(), Meteor.status().connected)
  }, [Meteor.status().connected])
1 Like
3

In Meteor 2.x, on a “new connection” for a logged-in account, this is the behavior of Meteor.user() that I observed

  1. new connection
  2. login current user and Meteor.loggingIn() is true → Meteor.user() is undefined
  3. Meteor.loggingIn() still true => Meteor.user() becomes {_id, profile}
  4. Meteor.loggingIn() becomes false => Meteor.user() still {_id, profile}
  5. Meteor.user() becomes complete => {_id, profile, <other fields>}

Because of this, we consider a user to have completed login in the client by checking that <other fields> exist on the user object

4

Thanks, I will try this.

5

This might also be a workaround. But I would prefer to solve the issue on server-side, if possible. Maybe I am wrong, but I never experienced this behaviour on Meteor 2.

1 Like
6

The steps #1 to #5 are based on the speed of connection/query of the user account. If the steps are fast, you might not even notice it as if Meteo.user() is immediately available to your app. If it is slow, then it is noticeable.

If the bug is related to calling a method before the user is successfully logged in, then seems like the fix is to ensure that the user has successfully logged in before calling the method.