Currently, by default if I try to use social login in meteor, it will create a new account for the user if one is not available. But I don't want that. Here's what I need :
When the user signup, I need to provide social signup options. When the user signup with the social account, it should come back to the app where I will present the user with a form to enter extra details. I don't want to create an account until those details are filled. I will pull the name and email from social accounts.
At login, if the user have already connected a social account, he will be allowed to login. Otherwise he have to signup first.
How can I implement this behavior in Meteor?
The way I handle this is in Account.validateNewUser
this function validates the user and returns true or false.
but you can add logic to the process.
In my case, I check if the user exists by email:
social logins (except for Twitter) all create a user with email.
the function contains a user object parameter with the user account info
If you do a check using Accounts.findUserByEmail(<email>) you can find if the user has been created previously.
In that case,
there are 2 cases:
user tried to create an account with password, just return true and the rest of the user create process will prompt the user that a user already exists with this email.
if it's a social login, I merge the 2 user objects to make it one, keeping the original _id. then return 'true' to pass the validation process.
Related
I'm currently building a POS/Store admin app, when a user gets into my app, the Owner of the store will then be asked to login only once for setup purpose (e.g. a new machine), the app will then display a list of staffsName that has already been added by this owner, and then everytime a staff wants to start a new transaction, he/she will only need to click on his/her name, then enter his/her 4-digit pincode to 'login' and process the transaction.
How do i go about achieving this?
I was thinking of using firebase auth for the 'login' of the staff, but then when i log in using the staff credential, I will lose access to the uid of the owner, which is needed to access the owner's store data such as his/her products.
i'm also thinking of using firestore to store the 4digit pincode, but then i'm also concerned about security
There are multiple ways you can approach this, one where you utilize the email login by simply appending a fake domain to the username to create a valid email domain. This user account could be the designated 'user' in question, or utilize credentials inside custom claims or hidden in a database that allows the client or server (depending on your preference) to then log in as the user.
Moreover if you want the manager to login once you can add Authentication State Persistence to specify whether a signed in user should be indefinitely persisted until explicit sing out, page reload etc.
Another approach requires the user also to have a valid auth that is not an email password and you link your pin auth to that main account with Firebase Auth Linking per the documentation: https://firebase.google.com/docs/auth/web/account-linking.
This does however require that the user be registered from an auth provider such as Google, Twitter, Apple, etc. then the user will have to activate this link by logging in for authentication purposes. This can in theory be automatically generated and processed without the user knowing.
It is a long way around it since this is essentially a custom solution but it does create the flow you are looking for without having to use a custom auth provider.
hope you are well
I am trying to make an app where from the same app, you can either be a user or you can be a seller. In our case, the seller will be a restaurant and the User will be a restaurant-goer. My problem is that if I log in the "I am a restaurant login"-not a user login. On restart the app auto logs in and takes the user to the User homepage, not Seller homepage, as I am using the
auth.currentUser != null ?
Then add the home screen or login screen depending on auth state, but it is a general auth state. How would I make it show a different home screen based on the type of Logged in user. So I know why it takes me to the User homepage-I set it to do that, how would I make it takes me to one or the other
thank you
Firebase Authentication has no built-on concept of a type of user, so you will have to build that on top yourself.
You can store the user-type in the user's profile as a custom claim, or in a cloud-hosted database. In either case, you should do this from a secure environment so that user's can't change their type (unless your use-case specifically wants them to be able to).
So with that out of the way your app then takes these steps when started:
signs in the user, or restores their auth state.
determines their type.
redirects them to the correct screen.
Also see:
the links for How to create two types of users(Client , Freelancer. for example) while Auth using firebase in a flutter app?
How to create 2 different User group in Firebase AUTH with Flutter
many more results from searching for [firebase-authentication] two types of users
Please post the code you are using for this pathway.
I would advise you to create a property called userRole, and store this when the user is created.
When you send their name and image and email to Firebase after successful auth, store with that info their userRole.
In your widget tree, I'm assuming you have two widgets, CustomerHome() and RestarauntHome(). Now, after successful login, pass the user info to this widget, and check:
user.userRole == 'restaraunt' ? RestarauntHome() : CustomerHome();
This way, when they come back to the app, the page they are not allowed to see, will not be displayed.
Assuming you are using firestore database to manage your users' data, in the document of the users collection you can add a field of role whose value could be user or seller. Write to this field when a new user user/seller signs up. Then in the home page, return seller homepage when the value is seller otherwise return the user homepage. While the document is being fetched you can return the loading screen.
I've a project in which a user needs to be signed in by using their email and password credentials.The user must submit his unique id(Roll number) along with email and password at the time of his account creation.
While doing the project, I've used firebase-auth on the login page to use firease.auth().onAuthStateChanged() function.But the issue here is anyone can create their accounts by simply running firebase.auth().createUserWithEmailAndPassword() function in the console without submitting unique id(Roll number).
Now how can I restrict the users from such actions and making them to submit their unique IDs for their account creation
You probably do not want users to have to submit their unique ids when creating an account. If you do require this, then you'll need to add a validator that pings a collection with stored IDs to make sure that the unique Id they are submitting is in fact unique.
Instead, let Firebase create a unique ID for the user and allow them to register by email password.
Once a user registers with the firebase.auth().createUserWithEmailAndPassword() method, if successful it returns an object with auth credentials. in that returned object is a user property that includes a uid key:value
I have a current database with active users in Firebase that can login with user/pwd but now I'm implementing the facebook login and I realised the only way to link a facebook account with an existing user is only when the user is already logged with the user/pwd but not before the login.
I have two buttons in my app (login with fb and with email) but if I try to login with fb using the same email of an existing user, I will receive the following error auth/account-exists-with-different-credential and the documentation says that in order to fix this the user needs to login first then link.
Do you know if there is a way to link both accounts but without perform a login first, I mean, from the login view?
You need to sign in the user first before linking. This is important if you want to ensure it is the same user. Otherwise you can switch to multiple accounts per email in the Firebase console.
The way to solve this, when you get the error auth/account-exists-with-different-credential, the error will contain error.email and error.credential after you sign in with Facebook and the account already exists as a password account.
You then call firebase.auth().fetchProvidersForEmail(error.email) to which resolves with the list of provider IDs for that email. In this case, it will contain ['password']. You then ask the user to provide their password. You call signInWithEmailAndPassword(error.email, password) to sign-in the original user. You then call firebase.auth().currentUser.linkWithCredential(error.credential) to link the Facebook credential to the password account. Now both accounts are merged and the user can sign in with either.
I fixed it by going to the Firebase console. then head over to the authentication section and select the Settings Tab. Afterwards, go to User account linking and check Create multiple accounts for each identity provider
I am writing a web app for a client. Users will have a one-time key that they will use to initially identify themselves to the app. Once the app verifies that the key is valid it will take them to a page where they can create a normal account to use for all subsequent logins. The create-account page should only be accessible after entering the key and shouldn't be accessible otherwise. I.e, it shouldn't be accessible to users logged in with a normal account.
This is asp.net 3.0 using a custom membership provider.
My plan is to create a temporary account based on the key and authenticate the user with that account. This allows them access to the create-user page (which is protected with a location tag ) where they can create the formal account. I then authenticate them with their new account and delete the temporary account.
The flow is: the user goes to a page where they enter the key. If the key is valid I create the temporary account, call FormsAuthentication.SetAuthCookie, and redirect to the create-account page. This all works, although it seems a little complicated.
The problem is that the create-user page is available to any authenticated user; I only want it available during the time between entering the key and creating the formal account. So I thought I'd create a special role for the temporary account and make the create-user page accessible only to that role and none other. I created my own Principal object with a special role and tried setting it when I authenticate the temporary account but I can't get that to work.
I'm really hoping I don't have to write a custom role provider just to do this.
How can I make this work? There's gotta be a simpler way!
Why not simply create the real account when they enter the key. Assign it some random name and then let them change the name and other details. Then you don't need the create user page, just the enter key page and an account details editing page. If you're concerned about getting the account details filled in, you could set it up (perhaps via code on a MasterPage) so that incomplete accounts always get redirected to the edit details page until the details are entered.
Or, you could have them enter the required details in addition to the key code on the enter key page and simply use those details when creating the account.
My advice would be to avoid the use of temporary accounts when validating the user. Instead, generate your own logic for validating the sign-up key. Then, at the head of the page, you can check whether the user is an authenticated user (SetAuthCookie has been called) and jump to a different page if this is true.
You may even be able to change the page access to forbid this page to authenticated users (I know you can disable accounts for unauthenticated users but I'm not sure if you can go the other direction).
The key, though, is to avoid relying on the membership provider when, in fact, the user is not yet a member!
Assign an "incomplete" role when authenticating against the temporary token, then restrict access to only that role... when the account is created, send them to a re-login page (terminating the authentication token). This will simplify your security model.