I've working on a Firebase application and created a number of dummy yet authenticated users and data. I like to wipe the hole thing clean and start over. I can do this with the data but not the authenticated users.
In forge it says that if I delete my firebase I won't be able to create a new one with the same name. Though not the end of the world I find this mildly irritating.
Is what I want to do possible?
If you're using Firebase Simple Login email / password authentication, you can log into Forge (at https://<your-firebase.firebaseio.com) and manually remove the users under the 'Auth' panel.
For all other authentication types in Firebase Simple Login (such as Facebook, Twitter, GitHub, Persona, etc.), no user data is persisted, and thus there is nothing to delete.
UPDATED as of Feb 12 2015.
its in the https://<your-firebase.firebaseio.com?page=Auth
at the bottom, you will see the Registered Users.
Related
I have a Flutter app where most of the users should never log in. I also use this same app for a small selection of users that I personally manage and would like to allow them to create a Firebase account, preferably just with by giving them a password to access the account creation page. Ideally I don't want just anyone to be able to create an account, only those who I have personally given access to. Is there a way I could password protect the account creation page so that only those with access to the password could create an account? Perhaps there is another way to do this? Ideally, I'm not looking to get into a situation where anyone can create an account and then downstream I have to authorize that account so that it has the correct access. I really just want only those with the access upstream to be able to create the account. Perhaps this is not logical but this seems to make more sense than letting accounts be created by anyone and then approved by me after the fact. So my question really is, how do I password protect a page in flutter? Or is this just a bad idea and should I work to manage things downstream? Or is there another solution I have yet to consider?
Have you considered using something like a dynamic link that navigates to the specified page in the app when clicked. firebase_dynamic_links might be of help. Only those who have the link will be able to access it and I presume that you could manage the link actions from the Firebase console.
You could also opt for simplicity and create a password field that pops up before your account creation page
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.
I'm currently developing a web app using firebase authentication to make sure only authorized users can access the backend (e.g. firestore).
However, I don't really care about differentiating users but just want a single password based login/authentication. Meaning users come to the site, enter the password they know and then they get access to the protected data (e.g. from firestore). No need to create a own account.
However, I don't think firebase auth supports something like that.
What would likely work is just using .htaccess to protect the page and then provide users with anonymous accounts once they can access the app/page.
However, the browser popup caused by this is not nice enough for my purpose, I would prefer a nicely styled password form in the actual browser window.
What I could try is creating one account and sharing the password for that with all users (and set the email in the background). However, I'm not sure whether this works fine (e.g. multiple users being logged in at the same time on the same account).
Am I missing a simple option to implement such a single password based login shared between users?
Or is it e.g. possible to send a password to cloud functions, check it there and return an access token for an anonymous account from there to the user?
You can just create a single Firebase Auth email/password account and share the credentials with everyone. As long as you trust that each user will not share them with anyone else, and you trust that they will not maliciously overwrite each others' data, it should be fine.
I am developing an app for my college and there are different types of users called students ,teachers , hod's
etc. When they login, how do I know a teacher logged in, or a student logged in? Is there any function in firestore for role based signups and signins?
I was thinking that when a teacher signs up, I will add a tag end of her uid.username that if username is 'DANIEL' while signup, I will add a tea for teachers and stu for students at the end of the name what they provided.
So when they login i will get the uid and do the string manupulations and get the last three letters so that i can know who logged in so that i can show different UI to Different types of users
Is there any best way to do like this ?
while singning up user enters his username example:"daniel"
i will update that username in uid.username like this "daniel-stu"(if student signed up),"daniel-tea" if techer signsup.
Storing this information in the user's display name can work. You can read it back from there next time, and take action in your application's client-side code. But note that this means that any user can change their role, since they can also call the same code to update their profile. If that is not a concern for your app, then this approach sounds like it would work.
If malicious users should not be able to change their role, then you shouldn't set that role from the client-side application code. In that case, you can set the role from a server (or your development machine, or Cloud Functions) using the Admin SDK. Since the Admin SDK runs in a trusted environment, it has expanded privileges and can update the profile of any user. So the Admin SDK could update the display name of the user in the same way you have in mind.
But this still isn't secure, since you're still setting a property that anyone can modify for their own profile. Again... if that is no problem for your app that is fine, but if the use-case requires that you can rely on the property to be correct, we have to keep looking elsewhere.
The Admin SDK can set additional so-called claims on a user profile that client-side code can't modify. Such claims are for things that affect the permissions of the user, such if the user is an admin, or what role/group your users belong to. This sounds quite close to what you are describing, so can also be used. And this time, only your code that runs in a trusted environment will be able to do so.
Finally, you could store the additional information about a user in the database. It's quite common to have a collection (Users or Profiles) in the database, where you store a document for each user (with the document name being User.uid). You create the document when the user first signs in, and update whenever you need to. You can do this from the client-side code (if there is no need to control what gets written), or from code that runs in a trusted environment (such as your development machine, a server you control, or Cloud Functions) if you do need to keep control. A big advantage of this approach is that all users can potentially see the information in this collection, where the client-side Authentication SDK only allows a user to read their own user profile.
For more on this, see:
Adding new data to firebase users (in which I essentially list the same options with fewer words)
Add extra User Information with firebase (store the information in the realtime database)
Associate Firebase Users to Database Records (also using the realtime database for the additional information)
Cloud Firestore saving additional user data
this video explaining custom claims
and many more previous questions on this topic
I have created an Appcelerator iPhone app based on Firebase authentication, which works very well. But now I come across some unexpected behaviour.
My setup is as follows: on app start, the user must login or register. During registration, the account is created, and the corresponding account data (uid, name, email, date etc.) is also stored in a /users/uid data entry.
When I remove a user from Firebase through the Dashboard, by removing it from both /users/uid and the "Login & Auth" tab, it looks all clear. But when the user opens the app, he still remains logged in.
How can I enforce removing a user, where he is also logged out the next time he opens the app?
According to the Firebase Google Group, this is a known bug with Firebase:
This is a known bug on our end. As you noted, after deleting a user,
existing auth tokens are still valid and can be used to read and write
to your Firebase database. Security Rules are still enforced on these
tokens and that user will still only be able to access their own
Firebase data (if your rules are set up as such). Those auth tokens
will be valid until they expire. There is currently no workaround for
this bug although we are going to be fixing this in a future release.
https://groups.google.com/d/msg/firebase-talk/Yr_wn02q0bk/eTM9hop3paoJ
The only thing I can think to do is check whether you can read to your users area, and if there's nothing there, force a log out.
From your behavior it seems like there maybe a configuration issue or just a bug. Does the users information get removed from corresponding data-source (DB or in-memory store)? I would start there then move on to researching how the corresponding cookies/tokens work and contact their support.
Though perhaps you shouldn't out right delete the user, perhaps just disable the user therefore, accomplishing the same result? Maybe this behavior will work properly.