Authentication

docs/troubleshooting/authentication/_category_.json

@@ -0,0 +1,3 @@
+{
+  "label": "Authentication"
+}

docs/troubleshooting/authentication/code_403_the_caller_does_not_have_permission_status_permission_denied.md

@@ -0,0 +1,35 @@
+---
+keywords: ['permission', 'permission_denied', 'code']
+slug: /code-403-the-caller-does-not-have-permission-status-permission-denied
+title: 'Code: 403, The caller does not have permission. status: PERMISSION_DENIED'
+---
+# Code: 403, The caller does not have permission. status: PERMISSION_DENIED
+
+This error typically occurs when your application or service account does not have the required permissions to access a resource in Google Cloud or Firebase.
+
+## Code 403 Error Message
+
+You may encounter this error due to one or more of the following reasons:
+
+- **Invalid or misconfigured service account JSON file**
+- **Insufficient permissions** assigned to the service account
+- **Missing or incorrect IAM roles** for the service account
+- **API not enabled** in the Google Cloud project
+
+
+## How to Fix:
+
+### 1. Check your service account JSON file
+Ensure you are using the correct file and it is not corrupted.
+### 2. Verify IAM roles and permissions
+Make sure the service account has the necessary roles (e.g., Editor, Owner, or specific roles required for your use case).
+### 3. Enable required APIs
+Go to the [Google Cloud Console](https://console.cloud.google.com/apis/library) and ensure all necessary APIs are enabled for your project.
+### 4. Regenerate service account keys if needed
+If you suspect the key is invalid, generate a new one and update your application configuration.
+
+:::tip[Always Use Least Privilege Principle]
+When assigning IAM roles to your service account, follow the **principle of least privilege**—only grant the minimum permissions necessary for the task. This not only reduces the risk of misconfiguration but also enhances the overall security posture of your app.
+:::
+
+If you continue to experience issues, consult the [Google Cloud IAM documentation](https://cloud.google.com/iam/docs/troubleshooting-access) or contact support for further assistance.

docs/troubleshooting/authentication/custom_authentication_in_flutterFlow.md

@@ -0,0 +1,67 @@
+---
+keywords: ['authentication', 'api', 'configuration']
+slug: /custom-authentication-in-flutterflow
+title: Custom Authentication in FlutterFlow
+---
+# Custom Authentication in FlutterFlow
+
+:::info[Prerequisites]
+Ensure you have a **custom server** with login and sign-up endpoints that return a JWT token upon success
+
+**Custom authentication** must be enabled in FlutterFlow, with entry and logged-in pages correctly set
+:::
+
+
+Here's an example: 
+
+![](../assets/20250430121149388590.png)
+
+## Checklist for Troubleshooting
+
+### 1. Verify Server and API Endpoints
+    - Confirm that your server is correctly returning JWT tokens for login and sign-up requests. The server's response should include the authentication token, refresh token, expiration time, and user ID (UID).
+    - Double-check the API endpoint configurations in FlutterFlow to match your server's requirements.
+
+### 2. FlutterFlow Configuration
+    - Make sure custom authentication is enabled in the project settings.
+    - Verify that the entry point and logged-in pages are set correctly.
+
+### 3. UI Configuration
+    - To facilitate the authentication flow, ensure your app has at least three pages: 
+
+        **Login**
+
+        **Sign Up**
+
+        **Home Page** (i.e. the landing page when a user successfully authenticates)
+
+### 4. API Integration and Authentication Flow
+    - Test API calls from FlutterFlow to your server and ensure responses are received as expected.
+    - Upon successful authentication, use the backend FlutterFlow action to call the API. Then, utilize the response data to perform a "custom login" action within FlutterFlow.
+
+### 5. Handling Tokens and User Data
+    - Set up your FlutterFlow actions to correctly parse the API response, capturing the auth token, refresh token, expiration time, and user ID (UID). This data is crucial for managing user sessions.
+
+![](../assets/20250430121149749937.png)
+
+### 6. Navigation
+    - If automatic navigation after login or sign-up is not working, you can disable it. 
+    - Then, opt for manual navigation to ensure users are directed to the correct page after authentication.
+
+:::tip[General Tips]
+- Before integrating real user data, test your custom authentication flow using **dummy credentials** on your server. This allows you to debug token handling, API responses, and navigation logic safely—without risking user experience or exposing sensitive data.
+
+- Utilize logging both on your server and within FlutterFlow (snack bars, alerts) actions to track the authentication flow and identify any points of failure.
+
+- Test the entire authentication flow, from entering credentials to accessing protected pages after login, to ensure there are no breaks in the process.
+:::
+
+
+## More resources:
+
+https://www.youtube.com/watch?v=hnX3CvBtGvI
+
+**Sample project:** https://app.flutterflow.io/project/custom-auth-checklist-fdjkno
+
+https://docs.flutterflow.io/data-and-backend/custom-authentication
+

docs/troubleshooting/authentication/delete_user_action_is_not_working_properly.md

@@ -0,0 +1,33 @@
+---
+keywords: ['firebase-auth', 'delete-user', 'firestore-cleanup']
+slug: /delete-user-action-is-not-working-properly
+title: Delete user action is not working properly
+---
+# Delete user action is not working properly
+
+![](../assets/20250430121300815719.png)
+
+When a user attempts to delete their account, they may find that the delete action doesn't work as expected. Here are some tips for troubleshooting this issue:
+
+Understand that the delete action in Firebase is designed to delete the user from the auth table only. This means that the user's document in the database will not be affected. If you want to delete the user's document from the database as well, you'll need to create a custom action with some custom code.
+
+After you've completed the delete action, it's important to log out the user. This is because there is no longer a user connected to the authenticated user in the app. Logging out will ensure that the user is routed back to the login page, which is the initial page of your project.
+
+:::tip[Delete Related Data Before Deleting the User]
+Before calling the delete user action, make sure to first delete any related data (e.g., Firestore documents, Storage files) associated with the user. Once the user is deleted from Firebase Auth, their UID will no longer be accessible in the app session, making it difficult to reference their data afterward.
+:::
+
+:::note
+Keep in mind that if the same user uses the same signup method to log in again, Firebase will create a new document in the database for them. This is because Firebase will connect the new login information to the old user document. 
+:::
+
+
+![](../assets/20250430121301101693.png)
+
+:::note
+
+The action we do in Flutterflow is exactly the same action we can do manually to delete a user from the authentication table in Firebase.
+
+:::
+
+​

docs/troubleshooting/authentication/google_sign_in_troubleshooting.md

@@ -0,0 +1,72 @@
+---
+keywords: ['firebase', 'deployment', 'android']
+slug: /google-sign-in-troubleshooting
+title: Google Sign-In Troubleshooting
+---
+# Google Sign-In Troubleshooting
+
+If you face any issues using the Google Sign-In feature from the exported app, follow these instructions to resolve them:
+
+## 1. If the App is Pushed to the Play Store from FlutterFlow using CodeMagic deployment:
+
+- Deploy your app to the Google Play Store using the CodeMagic integration in FlutterFlow.
+
+    ![](../assets/20250430121439158816.png)
+
+- Go to the **Google Play Console**, open your app from the **All apps** list, and navigate to the **App Integrity** option under the **Setup** menu on the left.
+
+    ![](../assets/20250430121439605476.png)
+    ![](../assets/20250430121440000724.png)
+
+- In the **App Integrity** section, click the **App Signing** tab and copy the **SHA-1 certificate fingerprint** using the **Copy** icon.
+
+    ![](../assets/20250430121440426479.png)
+
+- Next, open the **Firebase console** and go to the project settings of the same project.
+
+    ![](../assets/20250430121440906814.png)
+
+    Scroll to the **Your Apps** section, select your **Android app**, and click **Add fingerprint**. Paste the SHA-1 fingerprint and click **Save**.
+
+    ![](../assets/20250430121441325585.png)
+
+- To update your configuration, open your app in **FlutterFlow**, go to **Settings → Firebase**, and click **Regenerate Config Files**, then click **Generate Files**.
+
+    ![](../assets/20250430121441664549.png)
+    ![](../assets/20250430121442125737.png)
+
+This should resolve the issue. Re-test to confirm that Google Sign-In works as expected.
+
+---
+
+## 2. If You Have Not Yet Pushed to the Play Store or Are Self-Signing Your App
+
+If you're not using Play Store App Signing or haven't deployed yet, follow our documentation to use **Keytool** or **Gradle's Signing Report** to get your SHA-1.
+
+Once you’ve generated the SHA-1:
+
+- Go to your **Firebase console** and open your project settings.
+
+    ![](../assets/20250430121442525774.png)
+
+- Scroll to the **Your Apps** section, select your **Android app**, and click **Add fingerprint**. Paste the SHA-1 and click **Save**.
+
+    ![](../assets/20250430121442863891.png)
+
+- In **FlutterFlow**, open your app and go to **Settings → Firebase**, then click **Regenerate Config Files** and **Generate Files**.
+
+    ![](../assets/20250430121443139294.png)
+    ![](../assets/20250430121443525154.png)
+
+Google Sign-In should now work correctly. Re-test to confirm.
+
+*For more information, refer to the [Google Play Services documentation](https://developers.google.com/android/guides/overview).*
+
+---
+
+:::tip[Add Your Debug SHA-1 for Local Google Sign-In]
+If you're testing Google Sign-In inside FlutterFlow or before deploying to the Play Store, be sure to **add your debug SHA-1 fingerprint** in Firebase. Without this, authentication will fail during development.
+
+After adding it, don’t forget to **regenerate your Firebase config files** in FlutterFlow under  
+`Settings → Firebase → Regenerate Config Files → Generate Files`.
+:::

docs/troubleshooting/authentication/how_to_retrieve_the_authenticated_type_from_firebase_auth.md

@@ -0,0 +1,61 @@
+---
+keywords: ['firebase', 'auth', 'authenticated']
+slug: /how-to-retrieve-the-authenticated-type-from-firebase-auth
+title: How to Retrieve the Authenticated Type from Firebase Auth
+---
+# Retrieve the authenticated type from Firebase auth
+
+Understanding which authentication method a user has used can be useful for several reasons. For example, it can be leveraged for analytics, user support, and to customize the user's experience based on their login method. This method, however, is specific to Firebase Authentication.​
+
+In our Flutter app, we can find out which method a user used to authenticate by leveraging Firebase's `User.providerData` property. Let's take a closer look at how this works in the code:
+
+```
+import 'package:firebase_auth/firebase_auth.dart';
+
+String getUserSignInMethod() {
+  final user = FirebaseAuth.instance.currentUser;
+  String signInMethod;
+
+  for (var info in user!.providerData) {
+    signInMethod = info.providerId;
+  }
+
+  return signInMethod;
+}
+
+```
+
+Here's a breakdown of the code:
+
+  - We first import the [Firebase Auth](https://pub.dev/packages/firebase_auth) package which gives us access to Firebase's authentication methods.
+
+  - Next, we define a function `getUserSignInMethod`. This function will return a string indicating the sign-in method the user used.
+
+  - Inside the function, we obtain the current user from FirebaseAuth using `FirebaseAuth.instance.currentUser`.
+
+  - We then declare a string `signInMethod` that will store the name of the provider used for sign-in.
+
+`user.providerData` is an iterable that provides UserInfo for each sign-in method used by the user. We loop over this iterable using a `for` loop.
+
+In each iteration, we assign the `providerId` to our `signInMethod` string. The `providerId` can be 'google.com' for Google, 'facebook.com' for Facebook, and 'password' for email and password.
+
+After the loop is done, the function returns `signInMethod` string which indicates the sign-in method the user used.
+
+The function `getUserSignInMethod()` returns a String value which corresponds to the providerId of the user's sign-in method.
+
+Here are examples of how the return value might look:
+
+- If the user has signed in using Google, the function will return: **`'google.com'`**
+
+- If the user has signed in using Facebook, the function will return: **`'facebook.com'`**
+
+- If the user has signed in using Email and Password, the function will return: **`'password'`**
+
+These are the identifiers used by Firebase to represent different sign-in methods.Please, thoroughly test this function to ensure it fits your specific requirements.
+
+:::tip[Use Sign-In Method to Drive Dynamic UI in FlutterFlow]
+In FlutterFlow, if you want to display or use the user's sign-in method in your UI logic (example, showing different UIs for Google vs. email login), you can create a custom function using the `providerId` approach shown in the article and **connect it to a custom action**. This allows you to make dynamic decisions inside your app based on how the user authenticated.
+
+Remember to return the result from the custom function and store it in an App State variable for easy access throughout your app.
+:::
+

docs/troubleshooting/authentication/my_app_is_starting_from_homepage_after_logging_in_once_in_the_run_mode.md

@@ -0,0 +1,25 @@
+---
+keywords: ['homepage', 'run mode', 'authentication state', 'session data']
+slug: /my-app-is-starting-from-homepage-after-logging-in-once-in-the-run-mode
+title: My app is starting from HomePage after logging in once in the Run Mode
+---
+# My app is starting from HomePage after logging in once in the Run Mode
+
+If your app always starts from the HomePage after logging in once (especially in Run Mode), this is likely due to cached authentication or session data in your browser.
+
+## Troubleshooting Steps
+
+- Clear your browser cache and history.
+
+![](../assets/20250430121300291232.png)
+
+- Try a different browser or use incognito/private browsing mode to see if the issue persists.
+
+If the problem continues, consider checking your authentication flow and session management in your app settings.
+
+:::tip[Reset Auth State for Accurate Run Mode Testing]
+When testing in Run Mode, **FlutterFlow retains your authentication state across sessions** unless explicitly reset. To simulate a real first-time user experience, consider adding a **"Log Out" button** on your HomePage that calls the `Sign Out` action. This ensures that the next time you run the app, it starts from the login screen rather than using stored session data.
+:::
+
+
+

docs/troubleshooting/authentication/safetynet_phone_sign-in_issue_on_android_devices.md

@@ -0,0 +1,55 @@
+---
+keywords: ['android', 'signing', 'release']
+slug: /safetynet-phone-sign-in-issue-on-android-devices
+title: SafetyNet phone sign-in issue on android devices
+---
+
+# SafetyNet phone sign-in issue on android devices
+
+It looks like you are experiencing an issue with using the Firebase Phone Authentication method. To troubleshoot this issue, there are a few things you can try:
+
+- Make sure you have correctly configured the Firebase Phone Authentication method in your  app. This includes setting up a project in the Firebase console and adding the necessary dependencies to your app.
+
+- Check that you have properly implemented the phone authentication flow in your app. This includes prompting the user to enter their phone number, sending a verification code to the user's phone, and verifying the code that the user enters.
+
+- Make sure that you have correctly configured the safety net and reCAPTCHA checks in your app. This may involve adding the necessary dependencies and configuring the keys in your app.
+
+- If you are using an emulator to test your app, try testing on a physical device instead. Emulators may not always behave the same as physical devices, and this could be causing the issue you are experiencing.
+
+- If you are still experiencing issues, try reviewing the documentation and tutorials provided by Firebase to ensure that you have correctly implemented the phone authentication flow in your app.
+
+    **Solution**: Read more information [here](https://firebase.flutter.dev/docs/auth/phone/)
+
+
+![](../assets/20250430121259958091.png)​
+
+To use phone number authentication, Firebase must be able to verify that phone number sign-in requests are coming from your app. There are two ways Firebase Authentication accomplishes this:
+
+## 1- SafetyNet:
+If a user has a device with Google Play Services installed, and Firebase Authentication can verify the device as legitimate with Android SafetyNet, phone number sign-in can proceed.
+
+To enable SafetyNet for use with Firebase Authentication:
+
+    - In the Google Cloud Console, enable the Android Device Verification (DEPRECATED) API for your project. The default Firebase API Key will be used, and needs to be allowed to access the DeviceCheck API.
+
+    - If you haven't yet specified your app's SHA-256 fingerprint, do so from the Settings Page of the Firebase console. Refer to Authenticating Your Client for details on how to get your app's SHA-256 fingerprint.
+
+The SafetyNet Attestation API is deprecated and has been replaced by the Play Integrity API. We are working on a migration path to the Play Integrity API, which we expect to make available within the SafetyNet deprecation timeline. After 31 January 2023, you will not be able to enable the Android Device Verification (SafetyNet) API in the Google Cloud Console. To enable the Android Device Verification (SafetyNet) API in a new project after Jan 31, 2023, submit the SafetyNet Attestation API Onboarding form.
+
+SafetyNet has a default quota that is sufficient for most apps. See [SafetyNet Quota Monitoring](https://developer.android.com/google/play/safetynet/quotas)
+ for more information.
+
+## 2- reCAPTCHA verification:
+In the event that SafetyNet cannot be used, such as when the user does not have Google Play Services support, or when testing your app on an emulator, Firebase Authentication uses a reCAPTCHA verification to complete the phone sign-in flow. The reCAPTCHA challenge can often be completed without the user having to solve anything. Please note that this flow requires that a SHA-1 is associated with your application. This flow also requires your API Key to be unrestricted or allow listed for "your-project-name.firebaseapp.com".
+
+The reCAPTCHA flow will only be triggered when SafetyNet is unavailable or your device does not pass suspicion checks. Nonetheless, you should ensure that both scenarios are working correctly.​
+
+:::info[Release mode]
+If you're releasing your app to the Play Store, you must add the SHA certificate fingerprints from the Play Console To get the keys for the release app, navigate to **Play Store Console > Your project > Release Management –> App Signing** and copy the **SHA-1** and **SHA-256** keys.
+:::
+
+
+
+
+
+![](../assets/20250430121300291238.png)