createUser Functionality Change

[Jay]

Firebase v3 eliminated the ability to create users in code on the fly without de-authenticating the current user.

This is really bad news for apps where there is a conceptual 'admin' or 'master' user that can create other users.

In our app for example, we have a master user (the owner of a 'company' within our structure) that can add sub-users to their company. With v2, createUser allowed for this.

However, with v3, createUser de-authenticates the current user and automatically logs in the newly created user.

That means to create a user in v3, the 'admin' user creates the sub-user in which the 'admin' user is de-authenticated so they then have to log back in. To do that, credentials would have to be stored in code to allow that automatic re-authentication (unless it's done manually, ugh), and that's bad.

Giving multiple clients that rely on our app access to the Firebase console is obviously out of the question.

While 2.x is 'still being supported', that's not really a good long term plan and not a good platform to develop on when it's an EOL product. e.g. Crafting an App that rely's on Parse cloud as the back end probably isn't a good investment at this point, right?

IMO, Firebase should not be a moving target for developers. Love v3 additional functionality, hate the way it was rolled out.

- Jay

[Jacob Wenger]

Thanks for the feedback, Jay. We are definitely internalizing it. I've got two follow-up questions for you to understand your use case a bit more:

• Are you running this code in the client or on a server? That is, are you using the browser SDK or the Node.js SDK?
  
• How did you ever enforce that only the admin can create a user in the 2.x.x SDK, since any old person (even an unauthenticated client) could create a user if they wanted to?

Thanks,
Jacob

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/50f60701-d68f-463a-9327-497e1e3acde1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jay]

The app is (was) Mac & iPhone/iPad based, Swift.

With 2.x, as you know, users can be created by anyone - and as was recommended by Kato early on and then Puf later (along with multiple responses to that question)... Who cares?

As long as they cannot access the data it 'doesn't really matter'.

The process is (now): our customers contact us, I create the initial company and admin user account and that admin user can then create the other users and permissions for their company (up to a limit). Conceptually the structure is

my_firebase
    company_0
       users
         uid_0
         uid_1
       company_data
         data_0
    company_1
       users
         uid_2
         uid_3
       company_data
         data_0

The users and other company data is sandboxed (via Rules) within each company and can only be accessed by users within that company. i.e. admin users cannot create a user (or access any data) in another company. Users that don't already exist within the users node of a company cannot access any data.

Ideally, we wanted the signup process to be automated and had it working until the Zapier relationship... dissolved? Or whatever happened.

When that was available, a new user (business owner) could sign up for the app, pay, create their company account and then create their users and other data for their company.

[Alfonso Gomez Jordana Manas]

Hi there Jay! Thanks for the comprehensive explanation. 

As you correctly noted, Firebase v3 eliminated the ability to create users from the client side without logging out the current user. 

We are working on server side SDKs that will allow for arbitrary user account creation from a privileged environment. Why the change? The main rationale behind this is having a more robust security model, that would be helpful if your app becomes a target for bad actors. For example, we will be able to apply different anti abuse throttling depending on whether calls come from an authenticated server, versus from an unauthenticated client -> this would help  us block malicious actors if they are trying to create fraudulent accounts for your app, but at the same time would give you full control from your own server, for advanced use cases like the one that you propose.

This new functionality will be ready soon (in the upcoming months), but until then, my best recommendation would be that you do not migrate to the v3 SDKs and keep using v2.

Let me know if this answers your question, and apologies for the poor support for your use case in the v3 SDKs right now. We will hope to be able to fix that soon :)

[Andre Kool]

I also came across this issue and found a way to still create users on the fly.

You basicly create a second firebase reference and use that to create the users.

Full answer can be found here

Op maandag 13 juni 2016 14:34:51 UTC+2 schreef Jay:

[James Proctor]

Hi Alfonso,

Like Jay, my application has 'Admin' users which create accounts for other users on the client side.

In your reply you indicate that you may make this possible again, but only on the server side.

Is there any chance of this feature being enabled in the client?

If not, how long can I rely on v2 being supported?

Thanks,
James

[James Spivey]

I hit this one today through Angularfire. I incorrectly believed it to be a bug in that API as I had read somewhere that it did not re-login. I like everyone else here have an application where the client manages all the users. This number will likely stretch into the thousands. Currently I will be giving the lone admin the rights to create users, and because of the data rules, only he will have any real ability to grant access to data. As it looks from my standpoint, with the exception of hacky workarounds, there would be no way for the system to work as I would be forced to create each backing user in the console and then having them create the user in the database, and then I would have to go back in and match them. That is very much not sustainable (or profitable). I have to agree that while I understand the argument to try and help with security, a lot of this still falls on our shoulders to protect our systems, so taking away any ability for us to even do something is overly prohibitive. It is on the developer to understand the weakness in their system. Could you imagine a wordpress site where admins could not create accounts for their editors? I would also note, firebase is wildly popular for the fact it helps trim backend systems out of the equation in many instances. To have to incur the extra cost of a node or java server that does nothing but create users adds not only unneeded costs but complexity. I have to throw my hat in the ring for please roll that back and allow for creation without login, if all bad actors can do is create a login, and then do nothing with it because of our enforcement rules, they have won very little. I also am not sure how the change really impactfully helps as now they still can create an account but now get auto logged into a system they can't do anything in, it does not in the end add to the protection of the system, more than it burdens those trying to use it. Especially those of us that did not find this out until we had already invested a fair amount of time into a new development on 3.x, I do not have the option of not upgrading. Id even be happy with just a configuration flag on the console that allows me to turn auto login on creation off. Thanks!

~James

[Alfonso Gomez Jordana Manas]

Hi James (both),

The best way to support this use case right now is what Andre Kool proposed above: using two instances of FirebaseAuth, one where you have the admin user logged in, and another where you can create users and log them in. This is supported (don't consider it a workaround), and should let you implement your use case. Let us know if you have any questions when trying to implement it.

We will be taking this feedback into account for future improvements of the product.

Thanks! 

Alfonso

[Carlos Matheu Armengol]

It works like a charm, thanks Andre!

El divendres, 24 juny de 2016 16:45:30 UTC+2, Andre Kool va escriure: