2

Is it possible to add an extra parameter or data to createUserWithEmailAndPassword function?

I have two forms to signup: one for users and one for companies. After creating the user an onCreate listener adds some additional information in the database. One thing I would like to add is a role (user or company). Therefore I'm looking for a way to add an extra variable to the createUserWithEmailAndPassword function that can get through to the onCreate listener.

Any Thoughts?

Thore
  • 1,918
  • 2
  • 25
  • 50
  • There is no way to store extra information like that inside of the Firebase Authentication user profile. The common approach is to store the extra information in a database (such as Firebase's realtime database or Cloud Firestore) keyed of the user's UID. See [1](https://stackoverflow.com/a/31039334), [2](https://stackoverflow.com/q/39076988), [3](https://stackoverflow.com/a/38527302), and everything linked from [4](https://stackoverflow.com/a/46657503) – Frank van Puffelen Jan 05 '18 at 14:26
  • 2
    Note that to add a role, you can consider [adding it to the profile as a custom claim through the Admin SDK](https://firebase.google.com/docs/auth/admin/custom-claims). Custom claims are small pieces of information about the user, which are made available in the Firebase Security rules. So if you want to use the user's role to drive their authorization, consider adding it as a custom claim. – Frank van Puffelen Jan 05 '18 at 14:28
  • I've read the documentation and watched the examples and use cases. 'Defining roles via Firebase function on user creation' is what I want. In the example, they give the user a custom claim based on their email. I want the same but based on the type of form they used and not based on their email address (if I understand the example well, a user gets admin access if his email address contains the word admin. Isn't that strange?). So my question is how I can a type in the onCreate function so I can check if it is an user or company that is signing up. – Thore Jan 06 '18 at 02:20
  • There is no difference in Firebase Authentication for those two sign-ups, so the difference is in your application logic. If I show you two email addresses, how do you know which one is from a company. If you can answer that, you can translate the answer into code that you then put into Cloud Functions. – Frank van Puffelen Jan 06 '18 at 04:22
  • No that's right, there is no difference in the Firebase Authentication, it's for my application logic. But to have the right logic, I need that extra type/role parameter in the Firebase Authentication Trigger, `onCreate`, so the admin SDK can store it in the realtime database. Or how else can I store this on a secure way? If I fire a function from the client side after the user has been created, the function can be fired again later on again to change the role, right? Same for working with a HTTP request function. It can be fired again later on. – Thore Jan 06 '18 at 12:17
  • Indeed, you can use the Admin SDK to set or change the role. What I don't understand is how you know what to set it to. Do you have a list of companies somewhere? Or are you pre-creating the company accounts? There must be something different about the process of companies signing up vs regular users, otherwise you can't differentiate between them in code either. – Frank van Puffelen Jan 06 '18 at 15:32
  • It's just a variable `type` with the value user or company. I don't have a list. It's just a two-sided system. Something like AirBnB or Amazon. People can get an account and companies can have an account. The flow and UI are different. – Thore Jan 06 '18 at 16:42
  • OK. So I'll assume that means there are two sign-up forms: one for people and one for companies. What keeps a person from going to the company form and creating a company account? – Frank van Puffelen Jan 06 '18 at 17:23
  • Nothing. It's possible but they will see other UI components with information they can't fill in (or fake) and in the end another price to pay. So it's really for showing the right UI components and routes. The only thing why I don't use a client side function to set the role to 'user' or 'company' is because a user could change himself, after he payed, to the role of company were he has more options to earn money while he paid less. – Thore Jan 07 '18 at 02:41
  • Ah OK. So if they paid a certain amount, they should get the "company" claim. Is the fact that they paid stored somewhere you can access from Cloud Functions? That would be the way to automate it then. If your payment provider supports web hooks (e.g. Stripe does), you can trigger a function when the payment completes and add the claim at that point. – Frank van Puffelen Jan 07 '18 at 15:30
  • Yes, that's an option I used before to handle free and premium users. But in this case, user and/or companies need to get the user of company claim right after they made an account. Otherwise I can't know which are the correct UI components and prices I have to show for each of them. – Thore Jan 07 '18 at 20:33
  • @FrankvanPuffelen Any further advice on how I can achieve this? – Thore Jan 09 '18 at 23:03
  • I'd expect that you keep track of what requests you sent to your payment provider and are able to tie those to specific users. That way when you get a payment confirmation, you can upgrade the correct user (and/or their company). – Frank van Puffelen Jan 09 '18 at 23:19
  • And for the actions (UI components, data that has to be filled in, different prices (user/company) that have to show up) in the meantime? A temperary user/company role set from the client side into the realtime database? – Thore Jan 10 '18 at 12:12

0 Answers0