0

I'm wondering if it's an okay practice to set a uid variable onAuthStateChanged() and use this uid throughout my app to determine if a user is logged in or not. This way I don't have to use firebase.auth().currentUser.uid or have multiple onAuthStateChanged() methods throughout my code.

firebase.auth().onAuthStateChanged(user => {
  if (user)
    this.uid = user.uid;
  else
    this.uid = null
})

Even if a hacker changed this uid variable it still wouldn't give him access to a users database because of my rules, so is this an okay practice?

Now in my code I will check this.uid to see if a user is logged in and also use this.uid to retrieve user data.

I ask because I'm starting to use auth().currentUser a lot to check if a user is logged in and it would be much faster to just save the login status locally to this.uid when onAuthStateChanged, if it doesn't pose any security risks. This just seems like common sense to me but I'm still new to Firebase and haven't seen this practice in the examples so I have to question it.

Daniel D
  • 918
  • 9
  • 18
  • 1
    There's nothing secret in an auth UID. It's common to store them wherever it's convenient, and you should have security rules set up for per-user storage when indexing by UID. – Doug Stevenson Jul 25 '17 at 02:00
  • 2
    The UID of a user is not a shared secret, but an identifier for a user (similar to how your UID on Stack Overflow is 8180588). There is no concern in others knowing it. See https://stackoverflow.com/questions/37221760/firebase-is-auth-uid-a-shared-secret/37222341#37222341 Btw: I also expect little performance gain from caching the UID. After the initial call, the lookup should be pretty instantaneous. – Frank van Puffelen Jul 25 '17 at 03:12
  • I understand. My concern was storing the UID in local memory as opposed to relying on the server side response when displaying user data. A user could potentially alter his UID to another user's UID. But I'm pretty sure my database rules would still protect from this. – Daniel D Jul 25 '17 at 03:55

0 Answers0