I use Firebase Firestore and Firebase Authentication in my project.
I am testing out what would happen if I go into firebase console and manually click the "Disable account".
I would expect that if the account is suspended, the authenticated user (test#mail.com in this case) will immediately receive error whenever a Firestore database is called (eg. getDocs(q) or setDoc()). The reason behind this assumption is that I assume Firestore tries to authenticate each call before doing CRUD.
However, after testing out, here is the test and result
Login user (test#mail.com)
Do a db read or write ensure everything works which it does
Go to firebase console and disable the account (test#mail.com).
Try to do another db read or write. The result here is that I was able to still read and write which is not what I expected.
So here are my questions
Is this a normal behavior?
Can I write Firebase security rule to overcome this issue?
It would be less idea if I have to check if user is logged in everytime I do a firestore call. But if that is what I have to do, how can I do that. I believe getAuth()and onAuthStateChanged is not really suitable in this case. Reason being getAuth() seems to only check the database the first time it is called. Any subsequence call it only checks the app memory and do not perform any network request at all (Verified by looking into console network tab). Which is kinda weird. And onAuthStateChanged does not listen to firebase state change, it only listens to if my app logs a user in or out.
Abit of background on what I am trying to achieve
I want to be able to lock a user out from my app by changing something from the db. And ideally not having to PING every few second .
Update:
It seems like it takes about 1-2 hour for my app to automatically recognise that the account has been disabled. It took takes alot longer than what I anticipated. I would still like to know if there is a better solution rather than wait though.
Firebase Authentication works with a combination of long-lived refresh tokens and short-lived ID tokens. The latter tokens are valid for one hour from the moment they are minted, and cannot be made invalid after they are minted.
So it may take up to an hour before your client gets a new token, and detects that its account has been disabled. You can force the client to update its ID token at any time by calling getIDToken(true). This will ensure the client has an updated ID token, but it won't invalidate the older ID token (since it's impossible to invalidate a bearer token).
What you'll want to do is write the UID or ID token to your database when you disable the user account, and then check for that in your security rules.
Also see the Firebase documentation on detecting token revocation.
Related
Is there any way to get to know the a user is already logged in any other devices ?.
In Firebase Auth service.
Anyone please let me know is there any predefined provision in Firebase Auth.
UserMetaData has the last sign in time. You can also set auth state persistence to be either local, session, or none.
You could use these to approximate whether a given user could be authenticated elsewhere, but it doesn't seem like there's data on whether a user is definitely currently authenticated somewhere. For that you'd need to store login/logout data separately, such as in a a Firestore document for each user.
Note that the auth service doesn't typically know (or care) whether the user is actively using the app... it just issues each user an authentication token, which is used over some period of time to prove that they are who they say the are. The token can be invalidated/refreshed from time to time for security reasons (according to the persistence setting), but it's not an indication of whether they're "active". You don't mention your use case, but if you're trying to figure out whether users are on or offline (say for a chat application), you should look at Firebase's offline capabilities.
I am building an app, where I need to use my own backend besides Firebase. I need to authenticate a logged-in user in my backend too. So I found this tutorial which does this. I send an idToken and verify this header in admin sdk in my node, based on the docs. I thought I could cache this token with redis or just a js map after the first verification for 10 minutes or as much as a user session would take, to speed things up, instead of verifying each request in a 10 min sess. I could probably cache the token in the phone too for some time?
My question is, what security consequences would this bring? Thank you.
To clarify I am not using custom tokens, I will be using the built in Firebase Authentication.
The convention is to send the ID token to your backend with every request. It's not expensive to verify the token with the Admin SDK as shown in that documentation. It doesn't cost any money.
Typically what you're supposed to do is use a listener to detect when the ID token changes (it will be refreshed automatically every hour), and keep using that token until the SDK delivers a new one to your callback. In web clients, you're supposed to use onIdTokenChanged to register a callback to get changes to this token over time. There is no need to persist or cache this token - simply use whatever the callback most recently provided.
Some of the Firebase backend services keep a small cache of recent ID tokens, and their decoded results. So if they receive the exact same token, they'll use the already decoded result. This is a riskless operation, as the decoding operation is idempotent: the same input will always deliver the same output.
I've incorporated Firebase Cloud Messaging into my app. After messing around, I kind of understood the premise of how it operates. So, as a result, I structured my code so that when users sign up the FCM token is stored. After creating two accounts, I realise both FCM tokens for the user were the same.
Looked online and sorted this issue, and now I can refresh the token on launch, and still append the new FCM token when users initially sign up.
So now, I ask the question - Users are created with a fcmToken field (which I can refer to in my code), however, due to the fact a new token is generated on launch each time does this render the token(s) stored for each user useless? Or can I still push to the specific user using the fcmToken?
I've looked online, but can't seem to find an answer.
FCM tokens don't uniquely identify an individual end user. They identify a specific installation of an app on a specific device. When sending with that token, it doesn't matter who is signed in to the app (or if anyone is signed in at all) - the app will still receive it and need to figure out what to do with it. It's up to you to decide what to do with that message, given the sign-in state of the user. If you expect that your app could have multiple users sharing a single app on a single device, then you will probably want to send something in the payload to determine who that message was intended for, if necessary.
#doug great answer, but there's a common implementation problem when people share a device, so please add a warning, something like: often only the last logged in user should receive push notifications, otherwise he could see messages from the person who was logged in before. your backend should not only store all the devices a user is logged in, but also for each device who the last active user is and check this upon sending a push. the question whether you receive push or not when logged out is a common topic, too.
I want to know if I need to re-authenticate with Firebase if I call firebase.database().goOffline and then call firebase.database().goOnline() at a later time. It is not clear in the documentation.
https://firebase.google.com/docs/reference/js/firebase.database.Database#goonline
The online status of Realtime Database is not related to the state of the user's authentication. Authentication state is handled automatically by Firebase Authentication. The token that identifies the user is automatically refreshed every hour by the SDK, and you don't have to write any code to manage that. It doesn't pay attention to whether or not the Realtime Database thinks it's online or not.
With Firebase Cloud Messaging for Web,
How do I maintain the list of valid tokens in my database? For example I've noticed when a user turns off notifications and revisits the site, a new token will be generated and the old token in my database is useless.
I've also tried using Firebase messaging.onTokenRefresh() callback, but it does not get called when I turned off notifications. Also in this case, even if it did get triggered, it returns a new token that was refreshed. How do I keep track of the old token that was refreshed?
Can someone please share with me their thoughts/ways to maintain and ensure the token list in the database are valid or up-to-date?
Any feedback is much appreciated.
Thank you,
Christina
messaging.onTokenRefresh() is probably a wrapper around the event onpushsubscriptionchange.
Indeed that event is currently only called when the subscription is enabled (or enabled again), but not when the permission for push notifications is revoked. So at the moment you can only know that an endpoint has expired when you try to send a notification to it.
More details:
http://blog.pushpad.xyz/2016/05/the-push-api-and-its-wild-unsubscription-mechanism/
In any case you can use the callback to send any new token to the server: at first you will have two tokens stored for the same browser, one expired and the other valid.
Some problems arise if you have data associated to the endpoint (e.g. tag) that you want to preserve during the endpoint change: see the blog post for some suggestions.