AngularFireAuth idToken emits a string instead of User

[markstuart]

Hi there, thanks for a great library, I've been using it on a large-ish project for a year or so.

I recently upgraded Angular/AngularFire/Firebase in the project and struck an issue with the account creation flow that took me a little while to fathom. It all came down to the change of behaviour of authState in 4.0.0-rc0, due to the underlying change in Firebase's onAuthStateChanged. After finding your changelog entry stating "The added AngularFireAuth.idToken: Observable<firebase.User> behaves as authState used to." I tried using it, but found the signature did not match what I was expecting.

Also, I read your v4 upgrade guide but didn't see any mention of the backward compatible idToken observable.

I have downgraded to AngularFire 5.0.0-rc.0 as a temporary workaround, to get latest version before idToken was altered.

Version info

Angular: 5.2.2

Firebase: 4.9.1

AngularFire: 5.0.0-rc.6

Other (e.g. Ionic/Cordova, Node, browser, operating system):

Expected behavior

idToken would be a drop-in replacement for users upgrading from pre-4.0.0 angularfire2's authState, as described in the changelog

This makes sense as it follows the interface of the firebase library's onIdTokenChanged which returns a nullable firebase.User

Actual behavior

idToken emits the result of the user.getIdToken promise to subscribers. This behaviour appears to have changed in this commit: 8ab3803

[jamesdaniels]

See #1069

[jamesdaniels]

Can you help me understand your use case? Happy to reevaluate the change or put something else in there.

[markstuart]

Hi James, thanks for getting back to me.

My use case is this:
On registration to our app we have a form which takes the user's firstname and lastname, as well as their email and password. We then chain some calls to firebase like this:

this.af.auth.createUserWithEmailAndPassword(email, password)
  .then((afUser: firebase.User) => {
    return afUser.updateProfile({
      displayName: [firstName, lastName].join(' ').trim(),
    }).then(() => afUser.sendEmailVerification());
  })
  .then(() => this.af.auth.signInWithEmailAndPassword(email, password))
  .catch((err) => {
    this.handleFirebaseError(err);
  });

Under pre-4.0.0 angularFire2, the authState subscription would fire after the createUserWithEmailAndPassword and after signInWithEmailAndPassword, allowing us to get a fully updated user and token to send to our backend API.

After the update, authState no longer fires after signInWithEmailAndPassword, so we only ever see a user object emitted from the createUserWithEmailAndPassword which has no displayName attribute.

I had hoped to just change af.authState.subscribe to af.idToken.subscribe and everything would work as before. The idToken subscription does fire at the same times as the old authState did, just that it provides a string instead of a User.

It seems odd to me that the idToken interface does not match firebase's onIdTokenChanged when authState matches onAuthStateChanged.

[kevintanhongann]

Have to agree with @markstuart that it should return the User instead a string, since I want to store the User information in cookie.

[markstuart]

@jamesdaniels It seems to me that one of the aims of the AngularFire2 4.0 upgrade was to simplify the authentication api, and in doing so bring it more in line with the Firebase library.

To me, the meaning of onIdTokenChanged signifies that the users authentication token has changed in some way, not that it should return a token.

Firebase provide it as a backward compatible way of detecting changes in the auth state (including refresh events), and it was originally your intention to do the same. Given that the AngularFire2 auth api is not extensively documented, and Firebase's api docs are rather more extensive (completely understandable of course, on both counts) it makes sense for the auth methods to follow the Firebase ones so that there aren't too many surprises like this one.

[jamesdaniels]

FYI We're planning on adding .user which will expose the user from onIdTokenChanged

[markstuart]

Thanks for the heads up @jamesdaniels, looking forward to replacing my hack of your original implementation of idToken (that did return the user) from our codebase once the user observable comes into play. Do you know what release that is likely to be in?

[jamesdaniels]

Addressing in #1642

[jamesdaniels]

Just cut rc.9, which includes the change

[bogacg]

Quick question @jamesdaniels :

do I still have to set & watch a meta-data in db and then trigger user.getIdToken(true) from client-side as expressed in example here in docs to get updated token/claim. Or token updates are automatically propagated behind the scenes now?

Update
I did re-create scenario in that example and yes, it is required to manually trigger (or by watching a meta node in Db) user.getIdToken(true) in order to get updated token. How ever auth service's new user & idTokenResult Observables are super useful. Thank you.

Update 2
Is there any difference with authState and user ? They seem to be the same.

[ghost]

Yes I am kind of confused to see that authState and user do the same? Is There any difference?