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.
Related
I want to use Firebase Auth for my user login/registration process. Everything else should be handled by my own backend (spring boot app + postgres db).
Now I'm asking myself how I can synchronize a new created user to my user table in postgres. I thought about the following:
REST call through client - Everytime I get a success event from the firebase sdk I call an additional request to my backend which sends uid, username etc.
Problem: What if my backend call fails but the register process was successful ? That would lead to an inconsistent state since (at least thats what I understanded) I can't easily rollback. That would lead to situations where a user can login into my app without my backend knowing the user. This would crash/ invalidate all my following queries (e.g. search after user xyz would lead to no result even though he/she exists)
Check the existence of the user in the postgres database
Here I would query the uid from the database (which I got from the jwt) and create a new user if it doesn't exists in every incoming request.
Problem: The user query is a unnessecary overhead for every incoming request.
Trigger with cloud functions - When I understood it right firebase auth is firing events when a new user is created in cloud functions. This could be used to make the external api call.
Problem: I dont know what happens when my external rest call fails at this point. Can I rollback the registration ? Will I be ever catch this event again ? I also proably would have an eventual consistency situation, since I dont know when the cloud function triggers. Furthermore I would prefer not to include cloud functions to my stack
Is there any way how I could do this in a transactional manner ? Did anyone else tried is using sth simular ?
Thanks for every help!
The easiest way is actually to not synchronize auth data, but instead decode and verify the ID token of the user in your backend code.
This operation is (by design) stateless, although Firebase's own backend services often implement a cache of recently decoded tokens to speed up future calls with the same ID token.
Apparently, I finally came up with a different solution:
Register user per Firebase SDK (e.g. with email + pw method)
Make a post-call to my own registration api including the resulting uid from the previous step and some metadata
API creates a new user including a column with the UID + Fetches the firebase token of the user and adds an internal claim that references to the internal Postgres UUID via Admin SDK.
Frontend gets the created user and hard refreshes (very important, since the previously fetched token won't contain the newly added claim !) the firebase token and verifies that it contains the token. If it does -> everything is cool, if not some oopsie happened :) That will require a request retry.
Later when you start your app you can just check if the passed token contains the custom claim, if not open the sign up/sign in page.
Every endpoint except the one for registration should check if the claim is set. If not just forbid the request.
How to set custom claims:
https://firebase.google.com/docs/auth/admin/custom-claims#set_and_validate_custom_user_claims_via_the_admin_sdk
You can use the Firebase Admin SDK to create the user account from your back-end instead of from the client.
So first you create the user in your database, then grab the ID and use it to create a user with the same ID in Firebase.
If all goes well, send a confirmation to the client and sign it in using the same credentials they entered.
Why not creating an endpoint in your backend service and call this endpoint when a client side authentication succeeds?
This method should do 2 things:
decode token to get access to Firebase user object (Firebase Admin)
Compare Firebase user with your internal user table. if it doesn't exist you can create it using firebase user object, otherwise do nothing.
This solution allows you to do other nice things as well (Syncing user info between Firebase and your internal db, providing a way to let a frontend know if this user is new or not, ...) at a relative small cost (1 get call per sign in)
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.
Firebase Official docs says that Firebase Token ID of a user expires in 1 hour . to generate a new token refresh token id is to be passed to an end point where in response the client receives new token id .
So question is that to keep a persistent Loged in behaviour in my react native app while user is not using app in foreground for hours would i have to start a background service that refreshes Firebase Token ID after every hour? or is their a better and easy way to keep firebase token id for users refreshed and keep user loged in.
Firebase Auth State Persistence (recommended)
The Firebase web API provides the following options for Authentication State Persistence:
local: Indicates that the state will be persisted even when the browser window is closed or the activity is destroyed in React Native. An explicit sign out is needed to clear that state. Note that Firebase Auth web sessions are single host origin and will be persisted for a single domain only.
session: Indicates that the state will only persist in the current session or tab, and will be cleared when the tab or window in which the user authenticated is closed. Applies only to web apps.
none: Indicates that the state will only be stored in memory and will be cleared when the window or activity is refreshed.
Using the Firebase state persistence API directly is by far the most straight forward solution.
However, if you are set on implementing state persistence from scratch using the Firebase Admin SDK, then you could do the following.
Custom State Persistence (not recommended)
User signs in.
The Firebase user ID and a secret token generated by the server are saved in storage, for example, React Native AsyncStorage. The secret token is also stored in a database.
While the app is running, refresh tokens are periodically retrieved to keep the session live.
User closes the app.
User opens the app.
App checks storage for the Firebase user ID and the secret token. If found, these are sent to the server to confirm if the secret code matches the code stored in the database.
If the secret code matches, the server then generates a custom auth token based on the Firebase user ID and sends back to the React Native app.
The React Native app automatically signs in the user with the custom auth token.
Use react-native-firebase lib.
I am using Firebase Web for a SaaS solution. My purpose is to have access to users' email at any time, either for sending notifications or triggering alerts from the backend.
For security reasons, Firebase auth does not allow to list users' email or to fetch emails based on user IDs. As a consequence, I keep a copy of the email into a specific collection in the Firebase database when a user account is created. The copy is made by a Cloud function that is triggered on user creation (following guidelines: https://firebase.google.com/docs/auth/extend-with-functions).
Thanks to the copy available in the Firebase database, I can access users' email. However, my issue is when a user changes his email.
Firebase auth provides the updateEmail function that returns a promise. I use this last to update the email in Firebase auth. Then, when the promise resolves I update the user email in the Firebase database. However, this has a major drawback: all the logic is performed on the client side and since both operations are not performed in a transaction if the client refreshes or closes his browser (or assume it crashes), then it is possible that Firebase auth is updated but not the Firebase database, thus leading to an inconsistent state.
I looked at the documentation, expecting the possibility to trigger a Cloud function when user auth information is updated. Unfortunately, I cannot find such a feature.
Another solution I thought about is to update the database from the Web client. Then, this last triggers a Cloud function that updates Firebase auth with the admin SDK. This last solution works but bypasses the check performed by updateEmail that ensures the new email is not used by another account. Also, the account hijacking protection performed by updateEmail is evicted, which is really bad from a security point of view.
Any idea to solve this problem properly is welcome.
Here are a couple of options:
When calling updateEmail, update the email in your database first before calling updateEmail. THowever, if an error occurs, you need to catch it and undo that change in your db.
When a user wants to updateEmail, send their id token and new email to your server or firebase function http endpoint. There you verify the ID token with the admin SDK, then use the client SDK require('firebase'), using the uid from the ID token, admin.auth().createCustomToken(uid), then using client SDK, firebase.auth().signInWithCustomToken(customToken). You can then call user.updateEmail(newEmail) on the backend and save the email.
Always save the uid only and just use Admin SDK admin.auth().getUser(uid) to look up the user and get their email. This guarantees you get the user's latest email as you will not be able to catch the email revocation if the user chooses to do so.
No need to save anything. Use the CLI SDK to download all your users and their emails. Check https://firebase.google.com/docs/cli/auth#authexport
This is also better as you will always be able to get the latest email per user even if they revoke the email change.
I have been using firebase chat and firepad for real time functionality in My Web Application which has multiple pages like a forum.
I started using the Firebase SimpleLogin too.I am able to login as a user and get the auth object which has the uid,id etc info.
1)Now if the user traverses to another page(i.e a new url(same application) is loaded ),does the authentication persist ? Ofcourse as we are manually doing the authentication by calling ref.login(),how can we know if the user is logged in when the second page is loaded.Will firebase store any cookie in user's browser or local storage ?
2)If the user is authenticated through firebase and now for for any request to my backend server for a new page ,how will I know that the user is authenticated.Should I be manually handling this by inserting some cookie in the browser or a hidden form field once firebase login happens ?
3)Is firebase Authentication suitable for multi page web application where the html pages and content are served from a back server other than firebase.?
I have checked the below question too.
Firebase JWT Authentication, Continually Send Token?
As long as browser cookies and local storage are both local storage is available on the browser, Firebase Simple Login sessions will be persisted across page refreshes on the same domain. Simply reinstantiate the Firebase Simple Login client via new FirebaseSimpleLogin(ref, function(error, user) { ... }) to restore a persisted session, if one is available.
Using this approach, your callback will automatically be invoked with the login state of the user. Note that you do not need to call .login(...) again to pick up a session, as calling .login(...) will always try to create a new session.
Once the user is authenticated, you can begin writing Firebase Security Rules, making use of the auth variable, which is non-null for any authenticated user, and will contain useful user information (such as user ids) when using Firebase Simple Login. See the 'After Authenticating' section of any Simple Login auth. provider page to see the exact payload.
In the event that you already have an authentication system you'd like to integrate with Firebase, or Simple Login is not sufficient for your needs, you can always generate Custom Tokens with your own custom data. These tokens can contain any arbitrary JSON payload of your choosing, which will be available in your Firebase security rules under the auth variable.
See the Firebase Security Quickstart for more information.