How do I reset user password in app without sending email link using firebase in flutter?
If you've already established the user's identity by signing them in, you can update their password
Letting a user change the password of an account that they're not signed in to, would be a pretty big security risk though.
If you have another flow for password reset in mind, you can always update the password of any account through the Admin SDK, which can be used on trusted environments such as your development machine, a server that you control, or Cloud Functions/Cloud Run.
Related
I am new to app development but wanted to start with flutter and appwrite. I want to build an app with Appwrite and Flutter. This app should have a restricted area were only registered users should have access.
I want to use a modified email/password authentication, with a phone number instead of the email.
I know how I can create a user with a phone number and confirm this number using the send secret. But I could not find anythig to get a session with only phone number and password.
Is my desired behavoir even possible with appwrite or am I just missing something?
Thank you in advance for your help!
Unfortunately, phone and password authentication is not supported. You can hack a workaround for this by using the email and password where the email is <phone number>#fakedomain.com.
What's your reason for not using Appwrite's Phone Auth system?
I need to implement a standard user registration/activation workflow with Firebase. There doesn't seem to be an obvious way to implement this. When I say "standard", I mean how most email/password accounts work - not necessarily specific to Firebase. I'm sure you're familiar with this. This is the workflow:
User enters their username/password on a form with some validation and submits details
The back-end creates the user record in the database, but the account remains deactivated (i.e. user cannot authenticate - the activated flag is set to false)
The back-end sends an email to the user with a link to activate the account
The user clicks the link in their email which triggers activation. This is probably a Web API of some description.
At this point, the user record's activated flag ticks over to true, and the user can now authenticate
The link probably also has a deep link that opens the app or navigates to a web page
The user can now log into the app
How do I configure Firebase to do all this?
Currently, the app allows the user to register. I am using the Flutterfire SDK. I call createUserWithEmailAndPassword, which successfully creates the user in Firebase. But, the user is already activated. The user should have a state of "disabled" in firebase until the account becomes activated. I can't find any settings to default the user to disabled when the account is first created.
I also managed to get Firebase to send out an activation email by calling sendSignInLinkToEmail, but this call is really designed for email authentication - not email activation. Opening the link should activate the account, but I have not figured out how to do this. This documentation makes it sound like it is possible. Perhaps, the Flutterfire SDK is missing this? I don't want to allow people to log in without a password. I only want to use this call to send out an email.
What am I missing here? Is this non-standard behavior for Firebase? If so, why? If the user is allowed to use an app with an email address that is not activated, they can impersonate someone else. We need to confirm at least that they are custodians of the email address that they are claiming to have.
Do other Firebase people just not worry about this?
Lastly, I know I can achieve this by creating a collection for users in Firebase and putting an "activated" flag there. But, if I do that, I've got to write a cloud function that accepts the link and then updates the user in the collection based on the received link. But I thought this would be automatic in Firebase. If Firebase doesn't have this built-in, I have to put all the security over the top to stop users from authenticating when they have not yet activated their account.
This is a pretty valid concern. I suppose the way around this is to check whether the signed-in user is verified whenever the app is launched. The User object that is returned from Firebase Auth has an emailVerified flag. Check this page for more details.
Using this flag you can choose to show a different screen or pop-up that has a button to send a verification link to the registered email address. Until the user verifies this address, you can limit access to some of the app's screens if you want.
Please note that I have not checked if this emailVerified flag is true for sign ups using Federated login providers like Google Sign-in and Apple Sign In. You might want to check that out.
In case a user forgot their password, how can I send them an email to reset it without firebase authentication?
As in they receive an email with a link that takes them to a page/webpage where they can reset their password and confirm the change, then they can login with their new password.
Assuming you are using Firebase Auth in your app: I don't know what you mean by "without firebase authentication?" That's not possible, but perhaps you mean through a specific means. Here are the two most common ways:
You can manually send a password reset by going into your firebase dashboard, go to Authentication, find the email, and on the right of the UID a menu icon comes up when you hover..you can choose to send a password reset email.
You can call this in a flutter app FirebaseAuth.instance.sendPasswordResetEmail(email: email);
How can we retrieve Kallithea admin user's Password, if forgotten it? The current setup is using its internal authentication plugin along with the default database SQLite. I can see the encrypted password in the database, but since it's encrypted, it's useless.
As the administrator is a normal user apart from its privileges, you can use Reset Password feature to regenerate (in the current stable release) or to change (in the forthcoming 0.3 release) its password. Even if you don't have email delivery configured, just check the logs — the password reset email is dumped there when there's no email delivery.
I think kallithea has no easy way of doing this, but when you use the original project ie. RhodeCode, there's a nice way to reset your account.
https://docs.rhodecode.com/RhodeCode-Enterprise/admin/reset-information.html#manually-reset-password
I've got a decent set of existing users on my website who login via their emailaddress as their username.
I'm setting up Facebook OAuth mechanism to allow new users to sign up more conveniently, but I'm not sure how to handle the scenario when a user who already has an email address registered with our system and now tries to login via Facebook.
Should I consider him the same user?
Should I treat him like a new user?
The situation is more complicated by the fact that I dont validate their email addresses (when they login directly into my system), so i cant assume they are the same user.
How do others resolve this conflict, or do other folks simply treat this user connecting via FB as a new entity?
On your login screen, users can have a choice: you may put
new user: signup using facebook
since this is a totally new user account, then you just need to do your facebook connect + request for email permission, etc.
existing user: login by email
Once they do this, let them login using the old-fashioned way. Then once signed in, prompt them to connect this email address to their facebook account. So the flow is login via email then optional facebook connect.
To do this, I assume you've added a field on your database table for user_accounts, that is facebook_user_id or fb_id or user_id, etc. Then on facebook connect, get the logged-in-email, UPDATE table SET fb_id = xxx WHERE email = xx
I've pondered the same issue. I think we'll go with the verified email (Facebook Connect) getting attached to and logged into the existing account with the same email.
Before we connect and log them in we'll explain that the account exist and ask for their password (they signed up using email and password, so they should know it) to ensure it's the right person.
If you support multiple external authentications (Google OAuth, Facebook etc) then you may not have a password, and in that case it gets slightly trickier.
If you do log them in to the existing account without asking for a password, make sure you clear existing sessions to avoid 'anticipation attacks', where an attacker anticipates that the target signs up, creates an account and keep the session after they've signed up and attached to the attackers existing account.