Firebaseui-web: [Feature request] Disable new user signups

[arhmnsh]

When a new user types their email address in the signin form, it shows the new signup form.
How can I disable this?
I just want the users who I have already created from firebase console to access my app.

[bojeil-google]

Hey @arhmnsh, that is currently not supported. It is not a common feature. In fact, it is hard to block that for OAuth sign in as you can't tell if the account is already created or not before launching the sign in to that provider. I am assuming you are using password sign-in in your case.

[krisdev-pl]

@bojeil-google but it's implemented in FirebaseUI for Android and will be shipped in version 1.2.0.
Here's the link: https://github.com/firebase/FirebaseUI-Android/issues/530
FirebaseUI for Android and iOS have feature parity so I assume it'll show in iOS as well.
It would be useful for users who have mobile app for their web app.

[krisdev-pl]

FirebaseUI 1.2.0 is already released, and mentioned functionality is present as per milestone: https://github.com/firebase/FirebaseUI-Android/milestone/13?closed=1
and issue: https://github.com/firebase/FirebaseUI-Android/issues/530

[arhmnsh]

@krisdev-pl hi! Thanks for the info. but this issue is to restrict new user signups for firebaseui-web, not for mobile apps :)

[Splaktar]

I'm trying to use firebaseui-web on a project atm and we're using EmailPassword Auth only with AccountChooser.com disabled. We need the ability to hide or disable users creating accounts.

Our requirements are that either we need to send them a special link for them to create an account or we need to manually add their account before they login.

Currently there does not seem to be a simple way to disable account creation in firebaseui-web w/o forking the project. Please add an option to enable/disable account creation when using EmailPassword Auth.

[krestaino]

Would really love to see an option to disable new user sign-ups. I built a tool for internal use only, and there's no reason for anyone to ever sign-up. It's just a small pool of users who need admin access that I'd like to manage within the Firebase console.

[Moonwalker7]

Is this issue taken care in FirebaseUI version 2.3.0 ?

[rained23]

I am trying to disable sign up too because this make request.auth != null unusable for firestore, because everyone can just signing up an account and have the read access to the database.

one more thing is someone can spam a fake account on our authentication and how to prevent that ?

[bojeil-google]

@rained23 your question seems better suited for stackoverflow.
You can't disable sign up by using Firebase rules as it will also block users that you sign up on your end too and who later sign in.

FirebaseUI has plans to disable sign up but it may lack teeth as this seems like a feature better enforced on the Firebase Auth backend first. You are welcome to file an official request for it: https://firebase.google.com/support/ For now, we plan to return the isNewUser boolean on sign in via FirebaseUI. That will tell you if a user is new or existing. You could build on that but only enforce it on the client.

When you refer to fake account, do you mean fake emails? If so, you should send an email verification after FirebaseUI sign in and then monitor your users and delete those who do not verify after a while. Firebase Admin SDK provides tools to look up all your users and delete them if you want.

[nicolasgarnier]

Possibly this could be done with Custom claims: https://firebase.google.com/docs/auth/admin/custom-claims

You would have a server (you could use Cloud Functions with a user().onCreate() trigger or an HTTP trigger if you want to do this in a sync'ed way) that checks if the user is allowed to signup and add a custom claim to the user. For instance something such as allowed = true or false. On the client you could wait for the server to set this custom claim for the user, refresh the user and check if it is true or false and display the appropriate UI.

You can use the custom claims in the security rules to allow only users with the allowed custom claim to read data.

[bojeil-google]

Good suggestion @nicolasgarnier. I like that one.

[quincycs]

My use case: we want signup to be a back office process after contracts are signed. We don’t want sign up to be easy.

Due to this issue we are going to implement our UI in our own way via using the REST api.

[ralvs]

I think its a very useful feature for firebaseui-web!

For now, I'm using the workaround for auto disable new users using cloud functions.

const admin = require("firebase-admin");

exports.blockSignup = functions.auth.user().onCreate(event => {
  return admin.auth().updateUser(event.data.uid, { disabled: true })
    .then(userRecord => console.log("Auto blocked user", userRecord.toJSON()))
    .catch(error => console.log("Error auto blocking:", error));
});

Remembering that this function is also fired when you create users using the firebase web console. So you have to create, await the function, then enable the user.

[mesqueeb]

Since this is still open:
I also require google provider login but only for users who already exist. Block any attempts to login with a new google account that's not yet in my firebase user list.

[rained23]

I wanted to use firebase auth so I can reduce the development for
authentication, look at the situation just to disable sign up require a lot
of work, I moved to other provider which doesnt require me to do any code
regarding authentication which work mostly for normal cases. I think a
simple function like this which have many occurrence in most use case
should be available as Firebase known to try to remove most of backend
thing.

On Sat, Jan 27, 2018 at 10:57 AM, Luca Ban [e-mail] wrote:

Since this is still open:
I also require google provider login but only for users who already exist.
Block any attempts to login with a new google account that's not yet in my
firebase user list.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebaseui-web/issues/99#issuecomment-360954703,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA3YLYBDcAIJtnEt_rhj3zI6sKe7j8-9ks5tOpCjgaJpZM4Lso6u
.

[bojeil-google]

Hey @rained23, we should definitely support this use case and it is on our list.

I still think that @nicolasgarnier's solution is actually very feasible and doesn't require much work.
The only additional work you are doing here is setting the custom attribute when creating the account (to differentiate users your admins created) and adding a check in your Firebase security rules or ID token verification for that attribute.

Anyway, you can also submit an official request for this feature via Firebase support.

[mesqueeb]

@nicolasgarnier

For instance something such as allowed = true or false. On the client you could wait for the server to set this custom claim for the user, refresh the user and check if it is true or false and display the appropriate UI.

Do you mean if you retrieve the user from the server and then on the client side check for the value allowed and then display the UI according to that?

Since you have to check for the value on the browser side, there no stopping people from editing your front-end code and making allowed true just before it gets checked.

Am I correct and could this pose a security issue?
Or is there a safe way where the users on the front end can't mess with the values that came from the server?

[bojeil-google]

If you want to disable sign ups from the client, you would basically use the Admin SDK to create the user and set the custom attribute allowed on that user. Doing this via the Admin SDK ensures that only an admin can create the user.

In your Firebase security rules or if you are using your own server and verifying the ID token on your own, you would only allow users with that custom attribute to access data.

This has to be enforced on the server/security rules. Client side checks are helpful to show the appropriate UI and messaging to the user. They should not be relied upon. This is helpful if a user tries to sign up and the attribute is not there. You could also check isNewUser is true in UserCredential when signing in with the client and show the error message. Even if the user modifies the client, they still won't be able to access the data as your server will enforce that check.

[Floo0S]

Does anyone have a small code example for this workaround?

[mesqueeb]

If there could be a hook server side on login (even through google provider) I could set up:

If (!allowedUsersEmailArray.contains(user.email)) user.signOut()

I know this is front end code but that's the gist of what I'd want to be able to do server side with the great Firebase.

[quincycs]

I’ve got my own backend with its additional role checks already. If they can hack my app and still signup with Firebase, they still won’t be able to actually login to my app because I check for roles in my custom backend on every web api call.

[irmingard]

Here's my current setup, let me know if I've left open a loophole with that:

I have the following rules:
{
"rules": {
".read" : "auth != null && root.child('allowedusers').hasChild(auth.uid)",
".write" : "auth != null && root.child('allowedusers').hasChild(auth.uid)"
}
}

And as you can guess from above, I have an "allowedusers" object in my realtime database.

The behavior is the following:
While anyone is still welcome to try and login, they will be redirected to a denied.html page if their uid could not be found in the "allowedusers" object. When you want to add a new "alloweduser" retrospectively, you just have to add their uid to the "allowedusers" object.

Thoughts?

[bojeil-google]

You are better off just relying on custom claims:

".read" : "$user_id === auth.uid && auth.token.alloweduser === true",
".write" : "$user_id === auth.uid && auth.token.alloweduser === true"

This is way more efficient than having to lookup your allowed users on each request, especially if you have a huge list of users.

[Splaktar]

@bojeil-google do you have a link where we can read about how to set custom claims like auth.token.alloweduser when using Firebase? I have been doing something similar to what @irmingard posted.

[bojeil-google]

After you create the user. you would set the custom claim on that user via Admin SDK:

admin.auth().setCustomUserClaims(uid, {alloweduser: true}).then(() => {
  // The new custom claims will propagate to the user's ID token the
  // next time a new one is issued. Since this is created before the user signs in,
  // then when the user signs in, they will have that claim directly.
});

You can then enforce access via security rules without having to do any lookup:

{
  "rules": {
    "data": {
      "$user_id": {
        ".read" : "$user_id === auth.uid && auth.token.alloweduser === true",
        ".write" : "$user_id === auth.uid && auth.token.alloweduser === true"
      }
  }
}

[ShaMan123]

Thanks for this thread! Helped me a lot.
My contribution:
Combining custom claims with a rewrite to cloud functions called from FirebaseUI => uiConfig => callbacks => signInSuccess.

My Gist

documentation:
custom claims
rewrites
FirebaseUI => callback => signInSuccess

[mesqueeb]

@bojeil-google i'm still confused about the security. Even if the Admin can only set a custom claim through admin.auth().setCustomUserClaims can't the user just set {allowedUser: true} on their user object and get inside the database?

[bojeil-google]

This is stored in the ID token claims. The ID token cannot be manipulated without knowing the project's private key. Nothing on the client should be trusted. The ID token is the only source of truth.

[JorgeHerreraU]

How would I restrict sign up if I'm just using the web hosting service of firebase and not a database. It would be great to have this feature available within the firebase console.

[bojeil-google]

If you want to disable sign-up with the client SDK. The only other way to sign-up users is either via Admin SDK or via the Firebase Console. The above solution will work with the former since you have the ability to set custom claims but the latter currently doesn't allow setting custom claims.

[pashaseliverstov]

@bojeil-google , we need to have ability to create users without password with Firebase Admin in backend, and send email from the backend asking to create new password with FirebaseUI-web. How to implement this flow?

[bojeil-google]

You question is unrelated to the thread. Please open a new issue. In fact, it may be better suited for stackoverflow. It seems like you are better off creating an email account with Admin SDK and setting the custom claim there and using password reset flow, although, that flow is not really designed for account creation. After that, the user can sign in with email/password with FirebaseUI-web. If you want more information, I recommend using stackoverflow. It is better suited for system design questions.

[darkylmnx]

@bojeil-google that's indeed a needed feature, i came across a similar use case for a SASS i'm building.
I created all admin users upfront before launching in production, but the fact that anybody could just create a user from the console for example is problematic. When does this feature come around ?

Signup enabled must be seperate from signin enabled.

[jamesckemp]

I need this too, but the other way round. I only want to allow account creation via the UI. I assume there's no config parameter we can pass in to jump straight to the signup/signin part of the UI flow?

[bojeil-google]

The UI handles sign in and sign up. Blocking sign-up from the client app is quite common and I believe we should support it but this has to be supported first from the underlying Firebase Auth SDK. Many applications may not want to allow external users to create their own accounts. Having a sign up only flow is not a commonly requested feature.

[bojeil-google]

BTW, it may not be too helpful, but starting with version 2.7.0, we start returning a UserCredential like object which contains information whether a user is new or existing:

signInSuccessWithAuthResult(authResult, redirectUrl) {
   console.log(authResult.additionalUserInfo.isNewUser);
}

[mesqueeb]

@bojeil-google This UserCredential is of high interest to me.
I currently use the auth.onAuthStateChanged(user => { to check if a user was logged in, and perform a manual check if the user is new. (checking if his firestore is empty, if so create some boilerplate documents)

Is there a way for me to check wether the user is new or existing via the auth.onAuthStateChanged(user => {?

[wti806]

@mesqueeb Unfortunately, no. You can only check if use is new from the signInSuccessWithAuthResult callback.

[mesqueeb]

@wti806 Is there any example you could present of how to implement this?

I could find anything on this functionality in the documents: https://firebase.google.com/docs/reference/js/firebase.auth.Auth
Maybe it's still undocumented.

Would it work similar to an auth listener, also being effective on signin with redirects etc?

[wti806]

It's documented here: https://github.com/firebase/firebaseui-web/blob/master/README.md#signinsuccesswithauthresultauthresult-redirecturl

It works similar with signInSuccess callback in which you can pass in a callback function and it will be triggered every time on a sign in success operation.

[mesqueeb]

@wti806 it's only for firebaseui? I don't use firebaseui! Only native firebase with my own implementation. Firebaseui was too difficult to change language inside an SPA without page reload.

Any change this function will come to regular firebase?

[bojeil-google]

Hey @mesqueeb, this is the firebseui-web repo. Questions should be specific to this repo. If you have general questions on firebase-auth, you should post them to firebase-js-sdk.

[bojeil-google]

That said, there is no way to get UserCredential via onAuthStateChanged or after sign-in. You only get it on sign-in/reauth and link APIs. Firebase Auth does not manage 3rd party OAuth tokens and is only focused on AuthN.

[piotrpalek]

@bojeil-google
Do I understand correctly that this doesn't really prevent someone from signing up, only from signing in?

So for example, if I implement the suggestions laid out in your previous comment, I would still be able to call createUserWithEmailAndPassword from the WebSDK, and it would add the user just without the claim right? Or does it actually disable adding the user even in this case, if so could you explain how?

So to reiterate to make sure I understand it correctly, nobody can actually login into my app, but if they fiddle around in the debugger and grab a handle on the firebase SDK object they could register new users, but those users would be without the neccesary claim to login.

[bojeil-google]

This would disable access to your database for new and existing users if they were not created by you. The security rules will enforce that. From the rule perspective, it doesn't matter if the user is signing up or signing in.
Only the admin sdk can add the custom claim, and only the developer can do so. So playing around with the debugger is useless. The custom claim is encoded in the ID token and cannot be compromised unless the attacker has the signing private key.

[boonyasukd]

@bojeil-google

While it's proper to disable sign-ups from the back-end, as mentioned above, FirebaseUI Android can disable its sign-up functionality just fine. Why are standard on the Android and Web be any different?

To be honest, I simply don't think it's a proper response of you to use us to pressure Firebase back-end developers into implementing this feature _first_.

This "disable sign-up" feature surely needs to be tied from both ends (front-end, back-end), but to me the order of what gets done _first_ doesn't really matter. In fact, if you provide us this disable sign-up feature today, we can definitely use it in conjunction with custom claim in security rules, and that will work fine for most of us. Because, even if someone were to steal our apiKey JSON to create rogue users outside our webapp, at least these users can't gain access to our private data.

And, really, providing this feature on the front-end is still better than now, where there's absolutely _zero_ support, either on the front-end or back-end.

Also, regardless of security aspect of this, for apps that don't allow random people to sign-up, it's more than proper to not mislead visitors into thinking that they can sign up. Allowing random people to sign up just to deny access later is just unacceptable UX. User Flow is simply borked with how FirebaseUI Web works now.

[bojeil-google]

Android cannot disable sign up. You have to understand that client side cannot disable sign up. There are ways around it. This has to be an Auth backend feature.

The custom claim solution suggested here is a secure and correct solution. The downside is that it requires more work. We have plans to provide this feature out of the box.

[boonyasukd]

@bojeil-google

Sorry for being blunt, but do you even bother to read what I just typed at all? I know that sign-up cannot absolutely be prevented solely on the client side. I'm pretty sure everyone participating in this issue knows that. I'm also well aware of that. That's exactly why I mentioned above that rogue users can still be created if someone happens to know my apiKey JSON, but that's still a risk I can take, as long as the back-end is properly secured with security rules. IMO, it's up for us app developers to decide how to manage such risks, not you. All I'm asking is, let us manage our risk, and give us the Web UI that can hide sign-up screen, just like how FirebaseUI Android does.

As I said above, in Android, you can disable the sign-up screen:

https://github.com/firebase/FirebaseUI-Android/blob/master/auth/src/main/java/com/firebase/ui/auth/AuthUI.java#L625-L634

They have been supporting this since last year. And they still does support it now, even after a refactor to move the logic out from AuthUI.AuthIntentBuilder to AuthUI.IdpConfig.EmailBuilder. This is a fact.

[bojeil-google]

I will repeat this once again. This is not the correct way to do this. The Auth backend needs to throw an error on creation via client SDK which firebaseUI catches.
In fact, android only supports this for email/password creation. It does not cover OAuth and phone number sign in/ sign up. It is only a fraction of a solution.

[darkylmnx]

@bojeil-google there's something I don't understand, if we use a custom claim, isn't the custom claim going to be added for anybody signing up anyway ?

[boonyasukd]

@bojeil-google

I'm aware that the Android solution only works for email/password (hence the EmailBuilder above). But even then, I still believe a UI should be customizable even if it supports one identity provider. Besides, on the back-end, Firebase API itself already throws auth/user-not-found error when user attempts to log-in with email that doesn't exist in the system, so technically, it's already possible with email provider to prevent "automatic/accidental" Sign-Up (i.e., we only call Auth.signInWithEmailAndPassword() and never call Auth.createUserWithEmailAndPassword()). So, I don't see anything wrong if you were to implement this feature on email now, then follow up with other identity providers when back-end API changes in the future.

[piotrpalek]

@bojeil-google I appreciate the patience in explaining this over and over again :pray: I'll move over to SO if I have any more questions to not clutter this thread anymore.

[karansood]

@bojeil-google Hi, any update on when this feature would be available out of the box?

[lucaslugao]

One possible workaround for this problem is to test the user against a whitelist in the back end. To avoid filling up the project with a lot of users not in the whitelist you could remove them as they try to sign in.

[ajCastiglione]

Any news on this? I'm trying to build an app with firebase but there isn't an easy way to prevent random users from signing up without doing some hacky workaround.

[nietsmmar]

I would also love to have this feature. I've build an app, where users should be able to sign-up in my android-app but in the webapp-part they should only be able to sign-in, not sign-up.

[dandv]

I will repeat this once again. This is not the correct way to do this. The Auth backend needs to throw an error on creation via client SDK which firebaseUI catches.

Agree, but I think @boonyasukd means something different: we would simply like the auth web UI to be configurable to only show elements related to signing in - a matter of friendly UX, rather than security. Much like the Okta live widget but without the "Sign up" link at the bottom.

[arthabus]

@dandv As long as the issue #499 I've rise was marked as duplicate to this one, I'd add to your last comment that having "Sign up" link would be very useful as in our scenario we still need to provide both sign in and sign up flows but they shouldn't switch automatically as this leads to confusion.

[dandv]

Agree, I find the auto-switching confusing as well.

Plus, what if a user knows they've signed up already, but wants to sign up with a new account?

[pashaseliverstov]

This issue is opened for 2 years now!
@bojeil-google please add configuration parameter to disable self sign ups.
It is real problem for the end users. They keep using new email addresses and get disappointed after login with new email.
It would be also great to have ability to pre-populate email address at sign-in from the link the users receive in email.
At the moment about 20% of my users experience confusion at sign in because they keep entering new email addresses.

[bobbui]

this really sucks, I'm evaluating Firebase and disappointed by the lack of customisability. Considering not using Firebase.

[bdykzeul]

this really sucks, I'm evaluating Firebase and disappointed by the lack of customisability. Considering not using Firebase.

Just build your own UI and use the firebase auth API. you don't have to use the firebase-ui; it's optional

[dandv]

@bdykzeul: do you know of projects that have done this? I'm curious how fast the login is, because with firebase-ui, it's weirdly slow.

[Splaktar]

@dandv I have done it for the majority of my projects. It's faster, lighter on bundle size, and much more flexible and customizable.

[W357]

There should be an option to make signup an admin feature. Its a no go for business applications that anyone knowing the (not secret) api key can create user using the rest api.

[geekflyer]

Google released recently Cloud Identity for Customers and Partners (CICP) https://cloud.google.com/identity-cp/ which is based on Firebase Auth.

The lack of Firebase UI's ability to actually restrict sign up (in non confusing manner) to Customers and Partners makes firebase UI a non-starter for CICP's target audience (which in my understanding includes B2B / Enterprise apps).
Please consider adding this feature soon.

Since we're pretty much a google shop I wanted to like CICP but it seems in the meantime we gotta go with Auth0 which fully supports disabling of sign ups for email / password users.

[Splaktar]

I just found https://github.com/AnthonyNahas/ngx-auth-firebaseui recently and it supports disabling user registration. The one thing that it doesn't support is Phone Auth. So as long as you are using Angular and aren't using Phone Auth, that may be a valid alternative for your project since it doesn't look like this issue will be addressed soon.

[ep1703]

when new user create account cloud functions will trigger and admin sdk can make that user account disable, so it means it is possible to disable every new account
exports.BlockNewUser = functions.auth.user().onCreate((user) => { return adminFire.auth().updateUser(user.uid, { disabled: true }).then(function(userRecord) { // See the UserRecord reference doc for the contents of userRecord. console.log('Successfully updated user', userRecord.toJSON()); return true; }) .catch(function(error) { console.log('Error updating user:', error); }); });

[nietsmmar]

when new user create account cloud functions will trigger and admin sdk can make that user account disable, so it means it is possible to disable every new account

yes but for example in my case I got an app for phones and another app for web. One is for users one for customers. The web-app should only offer login and no sign up. The mobile app should offer both.

[cdock1029]

make that user account disable

Or just delete the user if you have all the users you want created.

export const preventUserCreation = functions.auth.user().onCreate((user, _) => {
  return admin.auth().deleteUser(user.uid)
})

Mix with whitelist strategy to allow for future dynamic checks for new users, that you can manage in the console.

I got an app for phones and another app for web

If it's 1 Firebase project and 1 pool of auth accounts, then what is the difference if they sign up through the admin interface, given the admin privileges must be granted some other way anyways (not simply by signing up)?

You could whitelist emails in a protected collection, then check list upon user creation to see if admin role should be granted, through customs claims for example.

export const checkAdmin = functions.auth.user().onCreate(async (user, _) => {
  const whiteListRef = admin
    .firestore()
    .collection('whitelist')
    .doc(user.email)
  const snap = await whiteListRef.get()
  if (!snap.exists) {
    return
  }
  await admin.auth().setCustomUserClaims(user.uid, { admin: true })
  console.log(`created user=[${user.uid}] set as admin`)
  return whiteListRef.delete()
})

If it's 2 projects then just use the delete user function for the admin project.

[sperochon]

Hello,

I have a web app with just email/password login using firebaseui. As a lot of people here, I do not want that new users can sign up themselves. I only want that only already existing users that I created myself can signed in.
So, here is the solution I've just implemented tonight. It can't answered to every case but I hope it will help someone...

_This is a 100% web client solution. No firebase function involved. So, to be 100% proof, you need to implement some security rules on server side too... as you already have should done with the normal firebaseui usage..._

Here is what to do :

1) Clone or download the source code of firebaseui-web
https://github.com/firebase/firebaseui-web
2) Do 'Developer Setup' (only 'Dependencies' and 'Building FirebaseUI' ; no need of Python or demo app) as described here : https://github.com/firebase/firebaseui-web#developer-setup

then choose one of the 2 solutions 3a) or 3b) (or try both) :

3a) Keep the same first sign-in page as usual
Open the file javascript/widgets/handler/common.js and replace the content of first 'if' of function 'firebaseui.auth.widget.handler.common.handleSignInFetchSignInMethodsForEmail' with

if (!signInMethods.length && app.getConfig().isEmailPasswordSignInAllowed()) {
    // Account does not exist and password sign-in method is enabled. Go back to
    // sign in with error message.
    var errorMessage =
      firebaseui.auth.widget.handler.common.getErrorMessage({'code':'auth/user-not-found'});
    firebaseui.auth.widget.handler.handle(
      firebaseui.auth.widget.HandlerName.SIGN_IN,
      app,
      container,
      email,
      errorMessage);
} else ...

or

3b) First sign in page is directly the page which asks login AND password at the same time :
Open the file javascript/widgets/handler/common.js and replace the content of first 'if' of function 'firebaseui.auth.widget.handler.common.handleSignInStart' with :

if (firebaseui.auth.widget.handler.common.isPasswordProviderOnly(app)) {
    firebaseui.auth.widget.handler.handle(
        firebaseui.auth.widget.HandlerName.PASSWORD_SIGN_IN,
        app,
        container,
        opt_email,
        opt_infoBarMessage);
} else ...

build, then test the resulting 'firebaseui.js' ;-)

As a bonus, you can even change titles or messages in translations of firebase-ui :-)

[tfesslerCWC]

Google released recently Cloud Identity for Customers and Partners (CICP) https://cloud.google.com/identity-cp/ which is based on Firebase Auth.

The lack of Firebase UI's ability to actually restrict sign up (in non confusing manner) to Customers and Partners makes firebase UI a non-starter for CICP's target audience (which in my understanding includes B2B / Enterprise apps).
Please consider adding this feature soon.

Since we're pretty much a google shop I wanted to like CICP but it seems in the meantime we gotta go with Auth0 which fully supports disabling of sign ups for email / password users.

I couldn't agree MORE!

Come on team Firebase.... This VERY relevant for Enterprise customers using the Firebase platform for consumer facing mobile applications who need Admin consoles to support the Firebase Architecture..

[bojeil-google]

We remain committed to supporting this feature (the secure way by disabling it server side first, and whose implementation is already in the works) and many more exciting features that are on our roadmap, some of which we already announced, including support for blocking (synchronous) functions and multi-factor authentication a couple of weeks ago. FirebaseUI will support both, Firebase Auth and Google Cloud Identity Platform.

[CraftedPvP]

Can't we just allow a 0 sign-up quota? the minimum is set to 1 for some reason. Setting it to zero could be also one of the solutions to solve this issue.

[nietsmmar]

Can't we just allow a 0 sign-up quota? the minimum is set to 1 for some reason. Setting it to zero could be also one of the solutions to solve this issue.

This wouldn't be a complete solution, as in my case I want to disable sign-up in my web app but not in my android app.

[ykamal]

Yeah Firebase, ya done mucked up. This is just bad. Over 75% of the apps I work on require internal registration and doesn't allow open registration. This makes Firebase completely useless to pretty much majority of my projects.

[Matesanz]

It's been two and a half years now... is not going to be such an implementation?

[Splaktar]

Yeah Firebase, ya done mucked up. This is just bad. Over 75% of the apps I work on require internal registration and doesn't allow open registration. This makes Firebase completely useless to pretty much majority of my projects.

@ykamal That's not quite accurate. It only makes you not able to use firebaseui-web, not Firebase itself. You can still use Firebase just fine by creating your own sign up and auth UI or using something like https://github.com/AnthonyNahas/ngx-auth-firebaseui.

[rynop]

@Splaktar I don't use firebaseui-web, and from what I've seen, a user doing a social/google login against FBase that does not exist, will be created. The only hack/workaround that works for me is a firebase function like the one mentioned above that disables new user onCreate. FWIW here is FBase function I use (the one in the comment I link to did not work for me):

const functions = require('firebase-functions');
const admin = require("firebase-admin");
admin.initializeApp();

exports.blockSignup = functions.auth.user().onCreate(event => {
    console.log("event", event);

    return admin.auth().updateUser(event.uid, { disabled: true })
        .then(userRecord => console.log("Auto blocked user", userRecord.toJSON()))
        .catch(error => console.log("Error auto blocking:", error));
});

[Splaktar]

@rynop that sounds like an issue that should be reported against the Firebase Admin SDK repo and not here in the firebaseui-web repo. I don't see an existing issue opened against the Admin SDK related to disabling new user sign up.

[tfesslerCWC]

When adding a user, I initially add them to a firebase table then I create the user. i also have a function for user onCreate that checks the table for the user being created against the table of users. if the user isn't in the db, I don't delete the just created user.

The lookup could go against the db of users or a temporary queue, where the record is deleted after the lookup passes in onCreate.

Yeah.. It's a bass ackwards approach that works well in every instance I've used it. Once the curve of understanding to get around the problem is passed... it's smooth sailing.

[Jarrio]

I would like to know the state of this issue? It is CLEARLY a wanted feature, why has it taken 3 years to not consider adding a simple toggle

if (toggled) {
   allowSignups();
} else {
   refuseFurtherSignups();
}

Sure this a bit of an oversimplification, but it really isn't that much more and if it is - at least communicate the internal issue so your users can try to relate to the primary concerns and would be more willing to compromise. As it stands this is just unnecessarily blown out of proportion.

Even outside of internal usage - alpha and beta tests are a thing for production purposes and controlling sign ups with what you intend to be your primary authentication methods just makes basic sense.

[jaunt]

My desire has to do strictly with GUI/UX for users who are non technical. Security is not my issue.

1. When I have sent them to a page to create an account, the widget should say "create an account", not "sign in". Or if I could hide that text, I could surround it by my own text.

2. When a user accidentally mistypes their email, they sometimes blindly enter their first and last name and password, and don't even see the that the header changed to "create an account".

What I want:

1. Option to hide the headings.
2. Option to only sign in, or only create an account. I.e. say something like "account doesn't exist" if a user tries to sign in with a non existent email account. Or "this account already exists" for creation mode.

[antonbehaeghe]

You are better off just relying on custom claims:

".read" : "$user_id === auth.uid && auth.token.alloweduser === true",
".write" : "$user_id === auth.uid && auth.token.alloweduser === true"

This is way more efficient than having to lookup your allowed users on each request, especially if you have a huge list of users.

After you create the user. you would set the custom claim on that user via Admin SDK:

admin.auth().setCustomUserClaims(uid, {alloweduser: true}).then(() => {
  // The new custom claims will propagate to the user's ID token the
  // next time a new one is issued. Since this is created before the user signs in,
  // then when the user signs in, they will have that claim directly.
});

I have a cloud function that sets the claims when a new user is created, but how do I edit the claims? Can I do this through the Firebase Console? The Admin SDK is server-side only and I only have a client-side app...

[wisammechano]

Please add a way to block new signups and have signups managed through the admin sdk

[chucklay]

Adding another request to fix this. There needs to be an option that can be passed in to disable the sign-up auto-prompt.

[shaibruhis]

Still waiting on a proper solution for this :/... Does anyone know if it's possible to log in via a curl command or something similar? That way I can make users in the firebase console and sign in through the curl command and not have to surface the UI at all.

[kimroen]

Just to add our usecase to this:

We have a mobile app where users can create users. When the user is created, the mobile app also creates a document for them in firestore in the users collection using the same id so that we can store other data and relations.

Because this was a mobile-only app to start, the mobile client does all this.

Now, we're starting to introduce some web functionality as well. To not have to build everything all at once, we wanted to allow existing users to sign in with email and password and manage some of their data.

As far as I can tell from this thread, we actually won't be able to do this with firebaseUI-web, because the user will create a Firebase Auth user that doesn't have a linked document in users, and everything in our system assumes that this document will exist.

We are going to migrate over and allow the web to create users over time, but we were hoping to deploy parts of this functionality at a time.

Am I right in saying that we cannot do this using FirebaseUI, and we'll have to implement the sign-in UI ourselves?

[janswist]

Hey @rained23, we should definitely support this use case and it is on our list.

I still think that @nicolasgarnier's solution is actually very feasible and doesn't require much work.
The only additional work you are doing here is setting the custom attribute when creating the account (to differentiate users your admins created) and adding a check in your Firebase security rules or ID token verification for that attribute.

Anyway, you can also submit an official request for this feature via Firebase support.

It takes you over 3 years to implement simple solution and it's still not yet her. You're limiting people to much and actually not doing much with it. How many workaround do we have to make because you have some more important issues to deal with?

[yuchenshi]

FYI, this is still on our roadmap.

[pashaseliverstov]

Could you please raise up the priority for this issue.

On Mon, Jul 6, 2020 at 1:19 PM Yuchen Shi [e-mail] wrote:

FYI, this is still on our roadmap.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebaseui-web/issues/99#issuecomment-654445200,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB37TWHWVZSAAMESNNHKIF3R2IWWJANCNFSM4C5SR2XA
.

[yuchenshi]

Could you please raise up the priority for this issue.

One of our teams is actively working on a feature that will unblock this. While we cannot commit to an exact release date, I can assure you that this feature request is being prioritized.

EDIT: More accurate wording

[pashaseliverstov]

Thank you for your response

On Mon, Jul 6, 2020 at 1:58 PM Yuchen Shi [e-mail] wrote:

Could you please raise up the priority for this issue.

One of our teams is actively working on this right now. While we cannot
commit to an exact release date, I can assure you that this feature request
is being prioritized.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/firebase/firebaseui-web/issues/99#issuecomment-654461847,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB37TWBVMSMS4VLY56Y2T7DR2I3IRANCNFSM4C5SR2XA
.

[katowulf]

(Locked for being too heated. Eng team will continue to update as they make progress and may unlock in the future.)

Keep in mind that we prioritize work based on what is most useful for our platform's target use cases. We can't solve every use case for every developer. Anyone developing an app or platform at scale understands that carefully choosing priorities and picking the best tradeoffs is a difficult, slow, and necessary process. This is one open source repo out of several, and we support 8 million developers. Less than a hundred requesting a feature doesn't translate to immediate changes to the product. Please keep the comments civil and constructive, and try to keep the bigger picture in mind.

[bojeil-google]

Support for disabling new user sign up has been added in v4.8.0.
Details on how to use this are provided here.

Note that the recommendation is to use this with server side enforcement via either blocking functions or disabling new user sign up to prevent malicious users from bypassing the UI.