I wanted to create a discussion about the best way to handle a situation such as when you can have users that login with Gmail, Facebook or simple email and yet they have a password change.
Should we allow a password change outside of the simple email authentication?
I think this is why we have fetchProvidersForEmail() method in Firebase 3. It creates a problem when a password is changed when a user's initial provider was based on Facebook authentication.
The Firebase 3.x documentation is a bit nebulous in terms of best practices.
Related
I'm working on a project where I'm using the authentification of firebase to use the forgot password thing. However, I have a collection users that I use as well and need the password field to be updated in the collection as well.
Any solutions please ? I can't seem to find a way to get password from authentification.
There is (very intentionally) no way to get a user's password from Firebase, and wanting to do so typically indicates an anti-pattern in your implementation.
If you already verify the user's credentials elsewhere, you shouldn't use Firebase to do the same (but for example mint a custom token based on the external credentials). If you use Firebase to verify the user's password, you shouldn't repeat that in your code (although you can for example decode the user's ID token to determine their identity).
i have an angular app which uses Firebase authentication - email provider. Works just the way, application wants it.
Now, i have a new customer who wants to use the application. The only issue is that he is not keen on having email addresses / mobile numbers as login identity. He wants to create his own usernames for their users to login. the username will be a string something like:
md, accounts, branchmanager, customer_with_weird_requirements etc
for attacking this situation, i have two approaches in mind.
changing the provider to customauth provider, bring in jwt and have a back-end endpoint
making the user only enter the username and suffix a common domain url like #abc.com and mock an emailauth provider
the following are the problem i have using the approaches
the app is fully powered by firestore and its web sdks. i need to start a new cloud function for creating the endpoint. well, not difficult but for just one module, we have a architectural change which i am not a fan
not the ideal way to handle auth module. also, reset password will not work as the rest link will be sent to the user#abc.com which doesn't exist in the first place.
Is there any way to use the providers available in firebase auth, with maybe basic tweaking, which doesn't make your email/mobile no mandatory?
What you want is beyond what the built-in providers of Firebase Authentication can be configured to handle. You'll have to create you own provider to support you needs.
Keep in mind that Firebase has some great examples of how to build a custom provider, like this username/password provider.
I am implementing Google Sign in in my VueJS App and I have a few questions before starting:
How to create a user when a user clicks on Google sign in button?
Do I have to create a custom route just for that?
Do I have to generate a random password because it is mandatory?
When a user is already registered and clicks on Google Sign in.
Do I have to pass Google Token from Vue JS to Symfony, then with google API, verify if token is valid and generate a token from my symfony application?
If you have some good documentation, I'll take it.
To get this started, it's actually a relatively complicated functionality to implement. This is because you'll have to use custom (maybe multiple if one can both login with Google account or register to your own website) guard authenticators. Moreover, you will need to use an OAuth bundle like KnpUOAuth2ClientBundle or HWIOAuthBundle.
The answer to your questions:
You have to create a custom route for that but you do not need to generate a random password, you can just make password nullable and add checks that it is null only for users logged in through Google (if it's not possible for you then just add something random as password). Additionally, I would propose to add a field provider to your User entity if you are providing both google and your own authentication. You should set this to 'google' or 'website respectively.
The user authentication process is being handled by Google and you are getting an access token as response that contains user's information like name, email etc, so you do not really have to worry about validating passwords etc.
This article helps you get started with KnpUOAuth2ClientBundle.
I'm trying to edit email address and password for other user via code. Is this possible to do without Admin SDK? I'm asking because I dont have backend skills yet. Does Firebase have a method to login user via uid? Maybe this way I will made my goal?
Users can only update their own data in mobile apps using the Auth client SDKs. It would be a gigantic security hole if any user could modify or log in as any other user without credentials.
On our app we are using "One account per email address". We want users to sign up using a specific authentication provider, which we keep track of, and stick with it.
What I've noticed today is that if I log in using a Google or Facebook provider I can then send myself a password reset link to the associated email address, which allows me to use the email/password provider instead.
There is a slight difference in behaviour depending on the first provider:
If I use Google first, after I use the password reset link I can now user either provider to log in, and both are linked to the same firebase uid. If I debug, I can see both in the providerDetails array on the authData object I get back from Firebase.
If I use Facebook first, after I use the password link the password provider replaces the Facebook one completely, although it retains the old firebase uid. At this point I can no longer use the Facebook login.
My questions are: is this behaviour intended, and, is there any way to switch it off?
This can cause confusion if say a user logs in using Facebook (which we track) and then later forgets and sends a password reset. It isn't the end of the world because they can carry on using the password login, but it certainly muddies the water.
Thanks
The behavior is intentional.
For end users, if they had signed into the app using Google or Facebook, and later they want to recover the password, the most likely reason is they (or an attacker) can not login with that identity provider.
After the user clicks the password reset link, Firebase removes the non-email identity providers to prevent other people from accessing the account silently. If the user still wants to add Facebook/Twitter login, they can do that via manual account linking (if the app supports).
In case the user's email service is the same as identity provider (e.g. #gmail.com users login into the app using Google), Firebase has an optimization to keep the identity provider since there is no security risk.