With firebase_auth in Flutter, how do you sign a user in with signInWithEmailAndPassword and handle the FirebaseAuthException it can throw?

## The call `firebase_auth` signs a user in with an email address and password through one method on `FirebaseAuth`: ```dart Future<UserCredential> signInWithEmailAndPassword({ required String email, required String password, }) ``` Both parameters are required named parameters. The returned `UserCredential` carries the `user` (a `User?`), plus `additionalUserInfo` and, for some providers, a `credential`. Creating an account uses the sibling method `createUserWithEmailAndPassword` with the same two parameters. Before either works, the **Email/Password** provider has to be enabled for the project in the Firebase console; otherwise the call fails with `operation-not-allowed`. On success, the method also updates the SDK's signed-in state, so every `authStateChanges()`, `idTokenChanges()` and `userChanges()` listener receives the new `User`. A well-structured app therefore **does not navigate from the sign-in button's handler**: the handler only signs in and reports errors, and the listener that already drives routing moves the user to the recipe feed. ## The exception type Failures arrive as a **`FirebaseAuthException`**, a subclass of `firebase_core`'s `FirebaseException`. It always has a `code` and usually a `message`; some failures also fill `email`, `credential`, `phoneNumber` or `tenantId`. Catch it with an `on` clause and branch on `code`: ```dart import 'package:firebase_auth/firebase_auth.dart'; Future<String?> signIn(String email, String password) async { try { await FirebaseAuth.instance.signInWithEmailAndPassword( email: email.trim(), password: password, ); return null; // the auth listener handles navigation } on FirebaseAuthException catch (e) { return switch (e.code) { 'invalid-email' => 'That email address is not valid.', 'invalid-credential' => 'Email or password is incorrect.', 'user-disabled' => 'This account has been disabled.', 'too-many-requests' => 'Too many attempts. Try again later.', 'network-request-failed' => 'No connection. Check your network.', _ => 'Sign-in failed (${e.code}).', }; } } ``` ## The codes that matter — and the two that no longer appear The pinned `signInWithEmailAndPassword` documentation lists these codes: | Code | Meaning | |---|---| | `invalid-email` | The address is malformed | | `user-disabled` | The account was disabled | | `invalid-credential` | Email or password is wrong | | `too-many-requests` | Too many attempts; the backend is throttling | | `user-token-expired` | The session's refresh token has expired | | `network-request-failed` | No network, or the request failed in transit | | `operation-not-allowed` | Email/Password sign-in is not enabled | | `user-not-found`, `wrong-password` | **Deprecated** — not returned on projects with email enumeration protection | The trap is the last row. Tutorials written before late 2023 branch on `user-not-found` and `wrong-password` to show "no such account" versus "wrong password". The source notes that **email enumeration protection** is the default for new projects since September 2023, and on such projects both cases collapse into `invalid-credential` — deliberately, so an attacker cannot probe which addresses have accounts. The emulator may report it as `INVALID_LOGIN_CREDENTIALS`. Code that only checks the two old codes falls through to its generic branch for every bad password. ## Good habits around the call - **Trim the email, never the password.** Whitespace in a password is a legitimate character. - **Show one message for bad credentials.** Matching the backend's anti-enumeration stance, the UI should not claim to know whether the account exists. - **Keep the fallback branch.** Codes are strings and the list evolves; an unknown code should still produce a readable message, ideally with the code logged. - **Guard `BuildContext` after the await.** If the handler shows a `SnackBar` after the call, check `context.mounted` first, since the listener may already have replaced the screen. - **Do not persist the password or the tokens yourself.** The SDK keeps the session; your own token storage is a separate concern. ## The handler, step by step 1. Validate the form locally — an empty field never needs a network call. 2. Disable the button, so a double tap cannot start two sign-ins. 3. Await `signInWithEmailAndPassword` inside `try`. 4. On `FirebaseAuthException`, map `e.code` to one user-facing message and re-enable the button. 5. On success, do nothing further; the auth listener replaces the screen. ## What the call does not do It does not verify the address — `sendEmailVerification()` on the `User` does that, and `user.emailVerified` reports the result. It does not route. And it does not throw on an unverified email: whether an unverified account may use the app is a product rule the app enforces itself, not an error the sign-in call raises.