I would like to use the signInAnonymously feature from firebase but I'd like to know how it works exactly.
Is this anonymous user added as any other user in Firebase (but without an email or password) ?
Is it automatically removed after a certain time ?
If I call this method on each app launch. Will it create a new user everytime ? How will it know how te reuse an old one ? Local Storage ?
So will it create another user in database if my users connects from another device ?
Thanks a lot
An anonymous user account is similar to any other user account in Firebase, except that there is no way to identify the user.
Anonymous users are not automatically removed.
Each time you call the API to create an anonymous user, a new account will be created. To re-use the existing account, you should listen for the auth state when the app starts and only create a new user account if the user isn't signed in yet.
If the same (anonymous) user signs in from multiple devices, they will get a separate account on each. If that is not what you want for your use-case, you should require one of the identified authentication methods (email/password, Facebook, Google, etc)/
Frank's answer to the third question is incorrect.
From the documentation:
If there is already an anonymous user signed in, that user will be returned instead. If there is any other existing user signed in, that user will be signed out.
Therefore, this method can be safely called every time the application starts.
Related
TLDR; Can multiple different users be authenticated and retain authentication via a generated custom token IF that custom token for each of those users is being generated always by the same UID? That is, User1 gets custom token generated by UID1 (via createCustomToken(UID1)) and then signed-in with signInWithCustomToken(), THEN User2 gets and signs-in with custom token generated using UID1, then User3 same thing etc etc, can ALL these users happily remained logged-in and experience no interruptions despite these other users being authenticated in this identical manner?
Long Version:
Ok, so I am trying to create a link-sharing system wherein a user who navs to this link can access a specific subset of my project's Firebase resources.
I have already tried using Firebase's signInAnonymously() to do this, but I dont like the way that Firebase does this for a whole host of reasons I dont want to get into.
The way i want to accomplish this is by:
generating a unique link (really a Firestore unique doc ID with some access data stored in that doc)
having the unauthenticated user navigate to some landing page, calling the cloud function and passing that unique link (lets call it a UID now)
cloud function, upon recieving this UID, will createCustomToken(UID), returning the token back to calling user
and the user will authenticate themselves with signInWithCustomToken(returnedToken) and access provisioned resources
Now, that is all well and good, but my question is:
If two (or any amount more people) people navigate to that same link and therefore pass and create token with the same UID, will they all be ok to continue happily using Firebase resources? Or is it because they got tokens created for them which utilised the same UID a sort of token-conflict is made, and therefore any next user who authenticates in this manner will revoke the previous user's auth token.
I havent been able to try this, and it seems like every question asked about these custom tokens relates to the generation and expiry time of them, which I understand. I wish the Auth docs were more clear on the mechnics and pitfalls of using Custom Tokens. I also havent been able to try it myself as it would be quite alot of refactoring, and was hoping someone could give me a straight answer to this.
Yes, a user can login on multiple devices without affecting other sessions at the same time irrespective of which auth method you use.
I'm not sure what the unique links are but it's not a good idea to pass the UID itself around if you function just takes a UID and returns a custom token as UIDs are pretty short and just a random string. It might be best to add a custom signed JWT in the links that contain the UID in payload so you can verify them before creating Firebase Custom Tokens.
I wanted to create website where I have separate Sign In and Sign Up form. I also want to have Google authentication with Firebase.
I've implemented it like this both on sign in and sign up page:
await FIREBASE_AUTH.signInWithPopup(googleAuthProvider);
But this code will always create new user.
What I would like to do is to block creating new user on sign in page, only log them in if user already exists (e.g. as I require terms of use consent on sign up page, but I don't want to require it on sign up page - it would be quite weird)
There is no way in Firebase Authentication to prevent users from signing up, while still allowing them to sign in if they're already created. The reason for this is that Firebase Authentication merely focuses on allowing users to authenticate themselves, so to prove who they are by providing credentials. What they can then do in your app is known as authorization, and is up to you to implement in your front-end application code, back-end application code, and server-side security rules.
For example, if you use one of Firebase's databases (Cloud Firestore or Realtime Database), you'll typically maintain a list of approved user's in that list (either their email or their UID). Then before granting the user access to specific screens in your app or data in your database, you check if the users exists in that list. If not, you don't grant access to the screen or data.
I don't see an issue here, when a user uses google auth when they already have an account it will create a new account with their in some cases new data he might have changed in his google account.
In case your users hold other data in your database I'm pretty sure there's a google auth API for that issue.
That's my question. I am using Hasura, and defining 'user' permissions.
Users are of course allowed to modify their own information, and not allowed to insert new records into my users table.
But when they signup, they should be allowed to insert themselves. So how can I define this permission?
To make my scenario more clear:
I have a React app, that uses an external OpenID provider. So a new user signs up there, and the provider returns a JWT to my app, containing a user I've never seen before.
My app does not know that, it just uses the access token to send to the Hasura backend to retrieve further info about this user, using the 'user' role. But it uses a query which will automatically insert the user if not found.
There's really not a safe way to allow sign-ups without involving a backend service. It is a very bad idea to allow anonymous inserts into your user table, even if you added a unique constraint against a user ID or email address.
If you have the option of using NextJS, see the Hasura example for configuring NextAuth. This works by configuring your app with a protected API route that uses your Hasura app's ADMIN_SECRET to insert new users who have authenticated with a third-party.
If NextJS isn't an option, Hasura's Auth0 example similarly uses a callback method to insert an authenticated user if they don't exist.
In the user table, for the user role, you need to add a permission with custom check. And the check should be user_id equals x-hasura-user-id.
{"id":{"_eq":"x-hasura-user-id"}}
For non-logged-in users, leverage the anonymous role by setting the permissions that make sense for your use case: https://hasura.io/docs/1.0/graphql/manual/auth/authorization/common-roles-auth-examples.html#anonymous-not-logged-in-users
Edit after the comment:
Ah, I see. When the user comes to your app, your app goes and retrieves some data that it expects every user should have (for example perhaps the user info store on the user table). But since it's a new user, this info is not there.
At this point, your React app knows that:
there's someone with a legitimately signed JWT cookie (use a library to verify the signature) and
there's no user info from the backend. Therefore, the React app shows
a "Welcome new user, wait while we're setting up your account".
Then
the React app makes a mutation to a signup Hasura action you'll
prepare. Once that returns, you proceed as usually (redirect the user to their home page).
use hasura action handler instead. Inside your handler, do a check if the user already exists or not. If not then insert a new row.
Is it possible to implement a function hook on when an anonymous user is linked to a normal account?
What I am trying to achieve in a secure way is:
1. DeepLink for invitation opens in the app.
2. Get invited_by from the URL and sign in the user anonymously, saving invited_by to invitations/anonymous_user_1/invited_by.
3. User registers an account and signs in so onCreate function is triggered, but we do not have access to the anonymous account there.
4. If there already is an anonymous account before registering, we link the anonymous account to the users new account.
And here is where I want to trigger a remote firebase function (don't want to trigger it on the client side, because it could be retriggered and abused to gain invitation advantages).
onLink() should do something like this:
1. Get old account (anonymous) and new account.
2. Get invitations/anonymous_user_1/invited_by from anonymous account.
3. Store it and perform actions on the new account.
4. Delete invitations/anonymous_user_1/invited_by once processed.
Is there a way to do this server side? Because onLink() would only be called once, and therefore I could process the anonymous data once.
As I said I would not want to call a function locally.
Thanks
There is no Firebase Authentication trigger for Cloud Functions when a user links accounts from multiple providers at the moment. As Doug commented, it's best to file a feature request for this.
I am working on Firebase application ( Firebase version 4.1.3 )
My health care related application is made for dependent group of people such as children and seniors. However, most of my users are independent group of people age around 18-55. Most of my users use my application for their seniors/children. They need to create account for each of their family seniors/children member. Therefore, my users have to log in and out many times and they have to keep track of their family members' account. My first thought was I should make an account switching feature so that my user can switch their account back and forth between their family members to update information on my application.
After searches on Google, I found way to force switching account on Firebase authentication with Google provider, but those are not what I'm looking for.
My questions are:
Is it possible to store the multiple firebase auth objects (logged in object) in client side?
If it is possible, for how long will the token inside the firebase auth object last for?
If it doesn't last forever, is it possible to refresh update the token so that it can be use without authenticating with the social/phone login again?
The functionality you are asking for is not available out of the box. You have to build it on your own. I do think Firebase provides the pieces to allow you to build it (via Auth and Database).
Is it possible to store the multiple firebase auth objects (logged in object) in client side: You can have multiple Firebase app instances and each one have an auth instance with a current user. You would need to ask each user to authenticate though (you can't authenticate once and sign-in into all of the account). However, you can build your own user group login mechanism, where logging in with one "master" account can allow you to login with multiple accounts using custom Auth.
If it is possible, for how long will the token inside the firebase auth object last for. Firebase sessions are supposed to be indefinite. If a token expires (typically after one hour), it can be refreshed automatically if you are using real time database.
I do not think Firebase has that token capability. But what you could do is simply put the email address of the people in the device by Shared Preferences( for Android). When the user wants to log in with that user bring the email address just ask him to enter the password and then go through the log in process. If you do not want to use SharedPreferences you could simply store the users(also as you said family members) in Firebase Database and link them with the controller user so to speak. Whenever user wants the switch, go and bring the email addres of other family members from Firebase Database and ask in the client for the password and do the login by Firebase Authentication.Hope that helps!