I am deleting a user from a firebase cloud function.
admin.auth().deleteUser(user_uid)
However, I was expecting that the following client side listener would trigger:
firebase.auth().onAuthStateChanged(() => // do stuff)
That is to say, the users deletion would also change his/her auth state from signedIn to signedOut.
The cloud-function call executes correctly, however the user is still logged in. Do I also have to log them out? (I see no admin .logOut method available.
I was thinking that after the successful Function execution I would then programmatically log them out from the client side.
Am I missing something?
EDIT: Deleting the user from the client side does trigger .onAuthStateChanged, so from the client side it does change his/ her auth state.
That's not the way auth state listeners work on the client. Those listeners trigger when the state changes from the perspective of the client. It doesn't know of changes that happen immediately on the server, at least not until the client tries to refresh its auth token. It's not "realtime" in connection with the server like Realtime Database.
If you want to wire up your own client notifications for user deletion, you could have the client listen to a per-user location in Realtime Database, and use the changes there to know when the user has been deleted.
Related
I want to know if the user has allowed notifications on the current browser so I can show that state on the UI, but I don't want to trigger the request permission unless the user performs an action to enable notifications.
This is kind of a chicken egg problem because I don't have a reliable way to identify the current user browser.
I can store the FCM token on the firebase database and fetch it on the FE. But each token is unique for each browser and I can not compare it to anything, the only way I have to check if one of the existing tokens is for the current browser is to use the getToken method from firebase FCM and check the returned token is on the list of tokens, but that may trigger a request permission prompt and I don't want that unless the user asks for it.
One possible solution may involve storing a flag on local storage, but if the user clears it the UI will show notifications as disabled when the user is still subscribed to the FCM topic. I know the Notification API has a property that indicates if the user has granted notification permissions but that may have happened and the token not retrieved for some random network error, so I can not rely on this solely. Also it only indicates if the user has granted permissions, but on my application logic notifications may be disabled (because user choice) and that does not revokes the permissions.
Things are also not nice if user wants to disable notifications: in order to delete the token from the database, I need the current browser token, and the only reliable way to know the current browser token is to ask it with getToken which may trigger a request permission if the user has disabled notifications and I will never get the actual token and I need it to remove it from the database
Are there any guidelines about how to deal with this? The FCM docs are quite sparse
This is a solution that I'm not sure if it is super robust, but it's simple and probably to meet most cases.
First, check if the current browser has notifications allowed. If not, just show that value on the UI because the user will not get the notifications anyway even if they are subscribed on the backend side.
If notifications are already allowed you can safely run getToken (will not trigger permission request) and compare the value against the values on the user/profile database.
Because I'm using react here is an implementation on a hook:
const areNotificationsAllowed =
Notification && Notification.permission === "granted";
useEffect(() => {
// because we don't want to trigger a permission request
if (!areNotificationsAllowed) return;
// Notifications are allowed, we can safely run getToken to see if they are activated on this browser
messaging.getToken({ vapidKey }).then((token?: string) => {
if (!token) return setNotificationsEnabled(false);
if (notificationsCfg[token]) setNotificationsEnabled(true);
});
}, [areNotificationsAllowed])
It seems like the firebase auth triggers are onCreate and onDelete. I'd like to also fire some kind of trigger on non-create login (basically periodically syncing the user's avatar and display name and such with what's in the database).
I can fake this by just doing it on the client side, which is what i'm doing right now - just updating the user record with whatever is in firebase.auth.user. Excitingly, this can't be done right after login, since if the login is also account creation, the user record tends to not exist (since it is created via a triggered cloud function), and I can't tell from auth.signInWithPopup() if the resultant signin was a creation or login event.
There is no such trigger. As you've observed, it just provides onCreate and onDelete.
Firebase Auth doesn't provide a way to sync the user's avatar with their authentication provider. It just copies the URL once at the time the account was created.
If you need to update the user's profile picture, you will have to do that yourself by calling updateProfile() on the user object and provide a URL for the picture.
I'm using angular in my project which user swPush. The notification works fine, but even after user1 logged out am getting the push notification. I don't want to push notification to the logged out users.After the user2 logged in both user1 and user2 getting notifications on the same device, this confuses the user. I want to restrict the user to get notification only when they logged in. How can I do achieve this. Is there any method.
I already try unregistering the service workers using
navigator.serviceWorker.getRegistrations().then(function(registrations) {
for(let registration of registrations) {
registration.unregister()
}
})
But after using this, both the users are not getting notification.
Thanks and regards
You should not unregister the Service Worker registrations because, well, that unregisters all of them. Unregistering Service Worker prevents any push logic from happening since web push is a layer on top of Service Workers - you need to have Service Workers registered and active in order to use push notifications, right?
You have two options if you only think about "showing the notifications":
When the user logs out, stop sending the push notifications. Of course this means that the web app logic has to inform your server somehow that now the logout event happened and precisely who it was (which of the possible different browser sessions of this particular user). Of course your server should already have information about the logout event.
Keep track of the logged in user in the browser (your JS code) and only show push notifications relevant to that user. You need to somehow distinquish between the receivers of the push notifications and the active user sessions in the browser and most likely handle it in self.addEventlistener('push', ...) in the SW.
If you think about privacy/security standpoint, the option #2 is of course wrong. If you only hide/not show the logged-out user's notifications, it means you're still sending them from the server. The notifications could include private information and whatnot.
So really you should go for #1. That's the right way to implement this. It leaks no information from the logged-out users, keeps the users' push subscriptions separate, and saves bandwidth.
I have a react native app that users can login or signup through it, I use firebase to log them in but I don't understand what am I supposed to do with the returned object from firebase.auth().signInWithEmailAndPassword(email, pass); and createUserWithEmailAndPassword(email, pass);.
Am I supposed to use one of the parameters it returns? how?
Is each backend call (my backend not firebase's) supposed to be with one of the strings it returns?
Also which strings should I save on local storage so the users won't have to login again? I set firebase.auth().setPersistence(firebase.auth.Auth.Persistence.LOCAL);.
Also which strings should I save on local storage so the users won't have to login again? I set firebase.auth().setPersistence(firebase.auth.Auth.Persistence.LOCAL);
This ensures that Firebase persists the authentication token in local storage. You don't need to do anything else. When the app restarts, Firebase automatically finds the token in local storage and re-authenticates the user with that information.
Most likely you will need to add a listener to onAuthStateChanged() to ensure you can update the UI of your app to this authentication state. For more on this see getting the current user in the Firebase documentation.
In the case of a SPA (Single Page application), the returned object from firebase.auth().signInWithEmailAndPassword(email, pass); should be used to set the user name, email fields and display photographs inside your protected app pages. Also, since the user is in signed in state you can display private links inside this promise. You can also update user's profile inside this promise.
In the case of a multi page application, you might check the profile verification status and then redirect to your app's home page on the basis of the same.
You are supposed to get the ID token in your backend to identify valid requests
Firebase automatically stores the current user data in local storage which persists till the user logs out or the localStorage gets corrupted(?). You can confirm this from the fact that firebase auth does not work in case of Safari private browsing mode as it doesn't support localStorage methods.
In short, nothing has to be done on your part to ensure data persists in localStorage, Firebase uses onAuthStaeChanged event listener to toggle sign in stage for a given user across all registered devices.
Is there any way to get the device token for notifications on demand with react native? It seems, from the docs, like the only time the token is exposed is on the PushNotification register event.
More generally, what's the common practice for handling device tokens?
If one user logs into my app, the app requests permissions from PushNotification, the register event is fired and I can associate that device with the logged in user. So far so good, but if that user logs out, and I break that association to stop the notifications, what do I do when another user logs in? The app already has permissions, so register won't fire again. How do I get the device token to associate it with the new user?
Or am I thinking about this the wrong way?
It seems my assumption that the register event only fires when the user grants access was the problem. The register event will fire in response to a call to requestPermissions whether or not the user was prompted. So by requesting permissions and responding to the register event when the app loads, you can always get the device id. Like so:
PushNotificationIOS.addEventListener('register', (token) => {
... store or use the token here ...
});
PushNotificationIOS.requestPermissions();