I am creating a login for my chrome extension where I am going to be using the firebase email and password.
I am going to be putting the create User firebase code on my website and when someone can enter in there email and the script will create a random set of digits and set that as the password. It will then email that password to the user and the user uses the email he entered and the random digit password he received via email to login.
My question is If a user signs up and then logs in with his email and password. Whats to stop him from giving that email and password to his friend and he also logs in. I want to control the amount of users I allow within my chrome extension and only want the person who logged in to use the chrome extension (I want so the login can only be used once) Is this possible for firebase or not?
Also If anyone knows a simpler method than that I described above with sending the email please let me know becuase to do that above I have to create something that sends an email and creates the password.
I would also like to know if firebase has something where I can set a date on a user and after that date passes the user is logged out and has to register again.
But my main question is that if a user where to register if he has the ability to share the login with his friend or if only he can use it.
I really appreciate your reply and help on my issue in advance Thanks A lot.
You'll likely have to do this from the server side (e.g. in a Cloud Function).
One option would be to use the session management features in the auth admin SDK: https://firebase.google.com/docs/auth/admin/manage-sessions - if you report back from the extension with the logged in user, you can revoke access for users who are seen in too many places at the same time. This limit might not be 1 - you may want to allow your users to log in on multiple machines at once.
For even more control, look at the option for managing your own session cookie: https://firebase.google.com/docs/auth/admin/manage-cookies - this allows you to set your own expiry and control the logged in state more granularly.
Related
I'm currently developing an authentication system with Firebase. I'd like my system to accept email/password, Google and Facebook as sign-up and sign-in methods.
So far, so good. Everything works good when the user signs up with each method separately. The problem begins when a user wants to sign up with another method and I need to link the new method to same account that was previously registered by the same user using another method.
My examples will mention only the email/password and Google methods.
Note: my Firebase auth system is set to accept only 1 account per email.
Example1 (works fine):
User register for the first time with Google
Perfect! I get his details and write it to the Firestore using the userID created by the auth system.
User tries to register again, now using his email/password (the same email from his 1st register with Google)
I get an error saying that the email is in use, I let the user know that he already registered with Google and I ask him to sign-in again with Google
Then, once he's signed in with Google, I let him create a password inside his account page.
I'll take that password and link it to his pre-existing account (which he is currently signed in) that was made when he first signed up with Google.
Great! Now I have a user that can login with either Google or his password.
Example 2 (the problem):
User registers for the first time using his email/password. Note that his email is one from Google (gmail).
Perfect! I get his details and write it to Firestore using the userID created by the auth system.
User tries to register again, now using Google sign-in method (with the same email).
Apparently everything works OK and the user signs in just fine.
But the fact is that, without any warnings, Firebase authentication has discarded his email/password method and replaced it with only the Google sign-in method.
Google Group - Firebase Talk - About this issue
From the link above and some other related questions here on StackOverflow, I understood that this behavior is like this because of security issues, and that is why Google has a "higher precedence" over other auth providers, since you can really trust those users and their emails.
But to remove a password that a user has created seems wrong to me. Not to mention doing it without any warnings.
And also, this seems to be in conflict with the following Firebase help page:
Firebase Help - Allow multiple accounts with the same email address
From the help page linked above:
You can configure whether users can create multiple accounts that use
the same email address, but are linked to different sign-in methods.
For example, if you don't allow multiple accounts with the same email
address, a user cannot create a new account that signs in using a
Google Account with the email address ex#gmail.com if there already is
an account that signs in using the email address ex#gmail.com and a
password.
From the excerpt above, what I understand is that I shouldn't be able to create the account using Google, if I have created it previously using a email/password combination. But that is not what happens, as per Example 2. Very strange!
Now the real question:
Since I'll not be able to change Firebase behavior, I'm thinking about changing my Firebase auth system to allow multiple accounts per email and handle all my users data in Firestore using their email as the primary key (instead of using the userID of the Firebase auth system), since every combination of email/sign-in method will be considered a different account in the Firebase auth system and therefore each one will have a different userID.
Ex:
johndoe#gmail.com / password = UserID X
johndoe#gmail.com / Google sign-in = UserID Y
johndoe#gmail.com / Facebook sign-in = UserID Z
All of the accounts above will store and access data in the Firestore using the johndoe#gmail.com as the "primary-key" (collection).
But since I'm early in my development, this seems a bit "hacky" I might bring some complications in the future.
What do you recommend? The main goal here is to let my users sign-up and sign-in using any method that they want to. All of the methods should allow them to access their data in my application (that will be in Firestore).
I refuse to silently delete a user's password that they previously created just to let them sign-up and in with Google.
Any other ideas or comments?
Sorry for the long question, but I think it illustrated the problem well.
One option is to enforce password users to verify their email address right after they sign up. In the example #2, Firebase will keep the account's existing password if the email address has been verified e.g. by sending a verification link to the email address and the user has clicked the link.
I am integrating FB Login in my website. For this purpose I am using Javascript SDK. Here are the steps which I am trying to follow.
User clicks on FB Login option, user is shown with POP UP by FB to enter his credentials.
FB sends response which includes accessToken, expire time etc.
After this user will see registration form dedicated to my website filled with email and other basic entries. He has to just choose some username and then click on signup.
As soon as user clicks on signup his details will be stored into DB, his username will be kept in session and he is signed in now.
User logs-out. Now, user again clicks on FB Login, if there is email already present in DB I am making the user log into my website by putting his username in session.
Here, are my questions now.
Shall I also store Access Token for the user in my DB in step 3? If yes then what will be the best encryption medium to send it to server-side?
Also, is there a need to store access token in cookie/session?
If answer to my Q1 is yes then will I be able to use the access token stored in DB to validate user if he uses FB Login again?
As far as I know once access token expires Javascript SDK will generate new access token. So, if user logs in after a long time then this validation might not be applicable.
Shall I also store Access Token for the user in my DB in step 3? If yes then what will be the best encryption medium to send it to server-side?
No, if you are not planning to do any automated tasks for the user with your server. In this case you'd need to change the access token to a long-lived token, but that's another thread.
Also, is there a need to store access token in cookie/session?
No, Facebook's JS SDK does all the access token handling for you.
If answer to my Q1 is yes then will I be able to use the access token stored in DB to validate user if he uses FB Login again?
No. You can save the Facebook User ID to your database, which is more constant than the email. Email can change, user id does not. So you should compare the user ID.
And just as a side-note:
Facebook also has a server-side login flow that should be used to authenticate the user. If you just use JS SDK to authenticate the user, it would be relatively easy to log in as any user imaginable from the client.
I am trying to remove a user programatically from my firebase. The method removeuser takes 2 arguments, email and password. Now email is not hard to find out since this is stored in the auth variable + I am adding it in my database when a user is created. However, how am I supposed to find out the password from the user?
When I create a user I do add the generated md5_hash information with this user in my database. However, I can not convert this value back to the real password.
I also obviously do not want to store the real password in the database since this is just asking for problems.
So I'm wondering, is there anything overly obvious I am missing here on how to remove a user programatically from the database, with his password? (Why do I actually even need his password to remove him?)
EDIT: To clarify, I am only allowing an admin to delete users, so he has a list of every user that has been created in my firebase. Having a user delete his own user account is still not so easy since (I presume) the firebase hashing algorithm is not public, so there's no way for me to check if he did input the correct password.
Firebase Simple Login is a service built on-top of Firebase Custom Login, and provides useful primitives for authenticating users via common means.
By design, Firebase Simple Login does not give you access to the users' passwords programmatically, as it only increases the risk that they are not handled or stored securely. Today, the only two methods that can be used to remove an email / password hash mapping is either via the client API using the email and password, or via the admin panel at https://<YOUR-FIREBASE>.firebaseio.com.
Keep in mind that when using email / password login, Firebase Simple Login simply creates a new mapping between an email address and a password hash, but does not store any information in your Firebase. Also note that there is no way to "blacklist" a user id, so if you remove the mapping, the user could re-create it.
If you want to ban / block users, a better approach would be to create a new list in Firebase of your "blacklisted" users, and then use security rules to ensure that that user is in the list (i.e. user is blocked if root.child('blocked-users').hasChild(auth.uid)).
Sorry for the generic title. I'm playing around with Mozilla's Persona at the moment. I'm using Express.js with the express-persona middleware so setting everything up was incredibly simple. The client-side part is easy too, but I'm having a hard time understanding one particular part of the documentation. It says:
loggedInUser: The email address of the user currently logged into your
site from this computer, or null if noone is logged in. For example,
you might examine the browser's cookies to determine who is signed in.
[...] Persona will compare the email address you've passed into
loggedInUser with its own knowledge of whether a user is currently
logged in, and who they are. If these don't match, it may
automatically invoke onlogin or onlogout on page load.
(Source)
express-persona sets a cookie which includes (I guess) the crypto-foo that acts as a password replacement. Am I supposed to store the email address returned by the backend in a separate cookie? That doesn't seem to be a very good idea. Maybe one of you guys knows how that's supposed to work.
You wouldn't store the email address in a cookie for Persona, any more than you'd store the username in a cookie for a password-driven login.
No, basically you do the same thing with Persona: Use a session, stored on your server, keyed from a cookie. The only difference is that your site went through the Persona auth process, instead of verifying a username + password.
The example on the page you linked to has a currentUser variable. Well, in a real web site, that variable would be filled in as a template from the server side. Do whatever you would do to support a login session, find the currently authenticated user, insert that user's email address.
I want to implement something similar to what Digg has done.
When the user logs in for the first time, I want it to force them to create an account on my site.
More importantly I want to know how to log a user into my site when they login with facebook connect. If they login with facebook connect, they still haven't provided me the password to their account on my site, so I can't use username/password to log them into my site. How do they do this on Digg or sites similar to this?
Facebook's process flow can definitely be a bit confusing. Take a step back from the details and the API, and look at the overall flow here:
Facebook Connect will tell you that a user is logged into Facebook, and give you their Facebook ID. You can validate that ID against Facebook using Facebook Connect to make sure it is properly logged in. Once this is done, you don't need a user name and password. As long as you trust that Facebook has authenticated the person properly, they are the only ones that can come to your site using that Facebook ID. That is enough information to start an authenticated session based around a local account that is associated with that ID.
The process you should follow is like this:
User logs in to your site with
Facebook Connect for the first time
You notice that you don't have a local account associated with that
Facebook ID, and prompt them to
enter local account information
You save that information along with their Facebook ID
The next time you see that Facebook ID (and validate that it is
logged into Facebook using the
Facebook API), you can start up a
local session using the associated
account.
Basically you end up with two separate methods of authentication: a Facebook Connect ID check, or the regular username/password login on your site. Either one should have the end result of starting a local authenticated session.
Hope that helps.