I am creating a messenger app. In order to register a new user what I want is to get email and password from the user and before creating the account I want to verify the email provided by the user.
But the problem with firebase email verification is that you have to create account/user first then you can send the email verification link to the user.
Now this can lead to major problem: Suppose if some fake user used my email and created account but failed to verify email. But still he manages to create an account with my email.
So if later I will try to register my self to the app then I am firebase is going to show me Email already used.
To solve this issue I want to delete account created if user fails to verify his email just after he tried to register himself.
To do this I created an email verification screen which is pushed as soon as new user register through his email and password. Now here app will be waiting for user to verify his/her email by clicking the link send by firebase. I have also provided a cancel verification button. So if user cancel the verification I am just deleting the account which was already created. I am also handling if user press back key without verifying email which will also delete the user account.
Main Problem: Now the the last thing I need to handle is if user force quit the app. In order to handle this I tried to delete the account in dispose method as well as I used WidgetsBindingObserver. But both of them doesn't work for me.
Please help me to solve this!
The idea of email Link verification was created to solve this problem. Instead of creating an account and then verifying the email after, the account is just directly created from your email. So obviously you must have access to the email to create the account. See https://firebase.flutter.dev/docs/auth/usage/#email-link-authentication for details on how to implement this style of link authentication.
A similar discussion of how to handle quitting the app is occurring here How to execute code before app exit flutter . However abrupt quits from an app whether done by the user or the system are hard to handle by nature.
I wouldn't recommend deleting the account when quitting/ closing etc. the app since it is something legitimate users may do before confirming their email (especially if the email is delayed in being sent for whatever reason). This will cause a lot of frustration.
You could setup a Cloud Http Task to trigger the deletion of that account after a certain time (e.g. a few hours) of the account not being registered.
If they do register in time, you can cancel the task before it runs.
Related
I created an amplify backend using the CLI. I used the manual process to set up the authorization amplify add auth and everything is working except that every time a user logs in they are prompted to verify their e-mail by the Amplify SignUp component
In the Cognito console I can see that their e-mail has been verified and the process of sending the code and entering it works as expected. But if the user signs out and signs back in they receive the prompt again?
I found my answer in the thread of this github issue: https://github.com/aws-amplify/amplify-js/issues/2730#issuecomment-468005207
During the configuration when I chose the read attributes I did not select the "Email Verified?" attribute. Since it couldn't be read it came back falsey and so amplifies SignUp component prompts the user to verify every time.
When updating user's email using admin.auth().updateUser({email: newEmail}) the user's email gets updated (as an authentication provider). But whenever I refresh the page, the user gets logout.
Is there a way I can prevent that from happening and keeping the user logged in after its email gets updated?
Firebase treats the email address as its primary way of finding the account for a user when you don't (yet) have their UID. For that reason the email address is considered sensitive information, and changing it requires that the user reauthenticates before they can continue to use the app.
The Admin SDK documentation doesn't explicitly mention this as far as I can see, but you sort'of derive it from the documentation on setting a user's email address.
I'm working on a app which uses Firebase Auth to signup and login, but I'm facing some things which I don't know how to start. Users need to registrate on a website and they need to pay a subscription before the user is created in firebase, when they don't pay anymore, the user account should be disabled. So basically, users registrate on the web and after they pay, they can log into the app with their credentials.
Edit:
Since yesterday I'm trying to implement either mollie or stripe, but I can't get myself started, online there are very few video's about payments in combination with firebase
There are basically two ways off the top of my headto do this:
A) Secure but it involves cloud function and creating custom authentication token to login.
User registers with email.
User keys in login information and posts to cloud function.
Find user's uid/email and check for password.
Fetch the subscription document and check if it is active.
If it is inactive, return an error message accordingly.
If it is active, create an authentication token and return to user to login.
B) Client side checking, less secure but will do the trick.
User logins
Fetch subscription using user's uid. Check its validity
Force redirect user to subscription page if it is inactive with
error message. OR Autologout user if it is inactive with error message.
May I also suggest Stripe for their subscription service (Not sponsored)? Unless you already have an implementation in place.
I am using Firebase Auth in my app. I update the email like follows:
firebaseAuth.currentUser?.updateEmail(email)
The email is updating 100% (I do a re-auth when necessary as well). My problem is after the e-mail has changed, the user is being logged out of his account and has to login again.
When I call
val user = firebaseAuth.currentUser
after updating the email the user is null and my app wants you to login again with the new email address.
Is this the correct behaviour? It makes for a really bad user experience having to login again after changing the account email.
I think Firebase is doing this on purpose for security reasons. You could work around this by calling the Firebase's login function automatically after changing the user's email.
However, I don't think that it is a normal behaviour if you're using the most recent version of Firebase. They explicitly state in their documentation that you need to re-authenticate the user to perform any profile change (if he hasn't signed in recently).
Some security-sensitive actions—such as deleting an account, setting a primary email address, and changing a password—require that the user has recently signed in. If you perform one of these actions, and the user signed in too long ago, the action fails with the FIRAuthErrorCodeCredentialTooOld error.
On my side, this effect only occurs on other devices on which the user has signed in, not on the device on which the edit action was performed.
UPDATE: it just randomly started working for me now...is there a period of time after updating an email that it is ineligible for new account creation?
I was able to use this API call provided by firebase to change emails for an account, but now I cannot use the other email to create a new count. I cannot reuse the other email at all. It seems like there is still a lock or hold on the old email.
https://firebase.google.com/docs/reference/js/firebase.User#updateEmail
Steps to reproduce error
signup with original#email.com
update account email to new#email.com (and click verification link sent via email)
cannot create a new account (nor re-update existing account) with original#email.com
I am simply looking to free up the email that is no longer in use. (original#email.com)
Note in image below that 'original#email.com' does not show up
This is a security related behavior. The old email is reserved just in case the owner of the email decides to revert to the old account by clicking the email change revocation link which is sent to the old email. This gives the owner of the account the ability to recover their account in case it was hijacked and the attacker tried to change their email.