I am trying to reset password for Firebase in iOS for a user who has email authentication as well as Facebook and Twitter authentication in Firebase.
The password is reset successfully and the user ID is the same, but the user's Facebook and Twitter authentication is removed (see below). How do I reset password in Firebase without removing social media authentication?
User authentication with social media linking before password reset
User authentication with social media unlinked after password reset
This issue also occur on Android
The following reply from a Googler seems to indicate that the unlinking is an intended consequence of the password reset to allow the user to recover their account in the case it was hijacked and modified by another user:
https://stackoverflow.com/a/44694017/1171539
First I would check the method they used to sign in:
You can lookup the providers linked to an account using: fetchProvidersForEmail
To reset the password, use: sendPasswordResetWithEmail
There are also instructions on how to send the password reset and redirect back to app: https://firebase.google.com/docs/auth/ios/passing-state-in-email-actions
see Firebase forgot password- how to identify whether user signed in with email or facebook?
Once you know the sign in method, if the method is email/password, you can call to specifically reset the password with email only. If it's social media then you can just not reset it, or ask the user to unlink the account, reset the password of the account, and relink the account if you're really determined.
Have you tried that?
Related
I've been facing a weird behaviour while implementing the email verification through Firebase. After creating an account through an Android app, I send an email verification for the user.
The email is being sent properly but it gets verified automatically even before clicking on the link (as in firebaseAuth.currentUser.isEmailVerified will return true after that). If the user presses on the link afterwards, it will say:
Your request to verify your email has expired or the link has already been used
This only happens with custom domains though. For example if the user uses a gmail account, everything goes normally.
Some more info
The credentials responsible for the email verification is restricted for HTTP referrers with https://{APP-ID}.firebaseapp.com for the APIs
Firebase Dynamic Links API and Identity Toolkit API
Any ideas on what might be happening?
Did you previously make an account with that email, verify the email, then delete the account? I had this same issue, it seems like firebase remembers email verification by email address, not by account.
This is likely an issue with firebase (albeit a rarer edge case in practical use), but if you're just doing testing, try using another email.
UPDATE: See comment below, it appears to be domain-related
I have added the EMAIL VERIFICATION PART in my project.
So every user need to verify their email before login.
But I want to add some user manually in Firebase, and I did that also into my project and I successfully added that.
BUT main problems is that when I try to LOGIN using that email I am having error message like "Please verify your email...".
But as I told you earlier I added user manually in Firebase, so I didn't receive any verification email into that perticular account.
So is there any way to login using manually added users into my app?
Firebase Authentication doesn't check anywhere whether the user has verified their email address. So if your app shows a message to that effect, it's either your application code, or a library that you use, that is show the message.
Normally a user's email address is only changed to verified if they follow the flow outlined in sending a user a verification email. You can do this from your application in the same place where it now detects that the user is not verified.
Alternatively, you can mark the user as verified using the Admin SDK, after adding them in the console. For an example of how to do this, see update a user profile in the documentation. Keep in mind: the Admin SDKs can only be run in trusted environments, such as your development machine, a server you control, or Cloud Functions.
I managed to successfully create users with a password using the Python Admin SDK, but I want to add Google suport, too. I understand I can have a link to sign in with Google in the app, but then the password is overwritten. I could have an option to merge the password with a Google account using linkWithCredential, but then the user still has to use the password at least once.
Using the Admin SDK, I first created a user normally then used the generated UID to re-import the user with Google.com set as a provider. The console shows that the user is able to sign in with password and google.com, but the password keeps getting rejected with ERROR_WRONG_PASSWORD (but password is still shown as an option when using fetchSignInMethodsForEmail).
How can I create a user that can sign in with both their password and Google?
I'm logging my users into our app using Google+. The actual G+ signing in happens on the server though. I get back some user data such as email and name. I'm using this to store the users credentials as a google account.
The issue arises when I try to save it. In the callback to save the creds in "Auth.CredentialsApi.save" it returns no resolution and nothing ends up happening. If I remove the Google IdentityProvider from the creds then it saves without a password.
Does anyone know why a resolution is not found when the IndentityProvider is set?
In Play Services 8+, no resolution (confirmation UI) is required to save a Google Sign-In to the user's Google Account using the Smart Lock API (i.e., the credential's type is set to IdentityProviders.GOOGLE and the email address matches one signed in on the device, and the user has not disabled saving in settings). Note that you cannot set both an account type and password on a credential object when saving with the API -- if a user has a password simply store that for authentication purposes.
An API call with a credential of this type should save automatically and be available immediately, so just check that this credential is available when making a Auth.CredentialsApi.request() using a CredentialRequest built with .setAccountTypes(IdentityProviders.GOOGLE) and that the saved credential is shown on passwords.google.com and has "with Google" in place of a password.
When retrieving this credential, you can use it to know that you've got a user with an existing account and they signed in with Google previously. You then can customize the auth UI for this returning user, or simply trigger a Google Sign-In flow for the user automatically and give them a returning user experience when the app starts using the Auth.GoogleSignInApi.silentSignIn() method in the latest version of the Google Sign-In library. Here's a full code example.
I'm trying to integrate an existing login system for a mobile application with some social media sign-in solutions. I successfully managed to integrate both facebook and google+ sign in with my app and I get to the point where the users are signed in and I can get their social information.
But now I was left wondering which would be the best approach in order to integrate users that decided to use a social media account with my native login system. Should I use their email accounts as login and maybe generate a password on the server side? Or maybe use an oauth token instead of a password?
I need to keep track of my users, even the ones that did not formally filled a registration form. So what should I place instead of email + password?
This can be tricky - the majority case is easy, but you need to think about the edges. I find it easer to consider email/password as just another authentication mechanism. You want
A user record with the core data about that user (perhaps name, email address, app specific profile data etc.)
A series of records for their connected auth methods, e.g. Google+, Facebook, user/pass.
The connected auth methods can store the relevant information for those methods - e.g. for Google it would likely be Google user Id and perhaps refresh token if using offline access. This makes it easy for you to offer connecting multiple social accounts.
Password may be a special case that you want to store against the original user record. In that case, if someone signs-up using a social login, then you can either generate a random password, or leave it null. Either way, as long as you request the email address for the user, you can always let them go through a Forgot Password flow (where you generate and email them a password) if they want to access their account but no longer have their 3p login.
What you don't want to do if avoidable is to force the users to give you a new password just after they sign in. However, it you are allowing multiple login methods to be associated with one account, you might want to allow associating them. So, your flow might be:
User signs in (with 3p or email/pass)
If you have a record for that login method (e.g. matching Google or Facebook user id, matching email/pass combination), sign the user in, and you are done.
If you have no matching record for that sign in method:
See if you have a matching email address with an existing user account. If you do, some sites automatically merge the new login method to this account. If privacy/security is more of a concern you might want to confirm the user wants to login to that account, or make them go through a 1-time validation (e.g. "it looks like you've signed in with a password before, please enter your password now to link your account and your Google account" etc.). Then link the accounts and continue as if signed in.
See if you have an account which may be that person. E.g, perhaps you have an account with a matching name. In that case, you might want to hint the user to connect their accounts (e.g. a prompt somewhere that says "have you connected before with Facebook? Click here to link these accounts" which then takes the user through a sign in process for the login method you suspect they might have).
If they look totally new, create a new user record, and treat them as newly signed up.
Its significantly easier if you can treat email address as a unique field. That means if someone signs in with a 3p account associated with an email address you already have a user for you might have to force them to link their account before continuing. If they didn't want to and you required an email address, you could prompt them to enter one manually and then validate it as normal by sending them an email and having them confirm it.
ChrLipp's links are good, also take a look at the guide for using FB and G+ together on the Google Developers site: https://developers.google.com/+/best-practices/facebook
How did you implement the social media sign-in's? For example Facebook: did you use Login for Android? In this case the docs say under Checking login status:
Apps using our SDKs can check whether someone has already logged in using built-in functions. All other apps must create their own way of storing when a person has logged in, and when that indicator is not there, proceed on the assumption that they are logged out.
And if you follow the link to Storing access tokens and login status you can read:
The token should be stored so it's available to all parts of the app when it makes API calls. ... If you're building a ... mobile app, then you should use the datastore available to your app. Also, the app should store the token in a database along with the user_id to identify it.
Have an enumeration (NativeLogin, Facebook, GooglePlus) and depending on this enumeration the following information:
NativeLogin
UserName, Password
Facebook and GooglePlus
Facebook or GooglePlus ID and their User Access Token
In all cases you should store the email adress you get in an additional field.