Just tried the documentation chat and this is the reply I got:

When using Supabase authentication in FlutterFlow, you generally do not need to manually store session data. Supabase, as your backend authentication provider, is designed to handle user session persistence automatically until the user explicitly logs out or their session expires. Here's a breakdown based on the provided context: * Automatic Session Management: Supabase manages user sessions using JWT (JSON Web Token) and refresh token mechanisms. When a user logs in, Supabase issues these tokens, which FlutterFlow's integration utilizes to maintain the user's authenticated state. * Session Persistence: The session is persisted across app restarts or backgrounding, allowing the user to remain logged in until they choose to log out. This persistence is governed by Supabase's internal settings for JWT expiry and refresh token rotation. * FlutterFlow Actions: FlutterFlow provides built-in actions like the \"Log In\" action to authenticate users and the \"Log Out\" action to terminate their session. These actions interact directly with Supabase's authentication service to manage the session state. * Supabase Configuration: Session behavior can be influenced by your Supabase project's authentication settings. For instance, jwt_expiry determines how long access tokens are valid, and enable_refresh_token_rotation along with refresh_token_reuse_interval manage how refresh tokens are handled to keep sessions alive. Setting Session Timeout to 0 is often recommended for longer-lasting sessions (effectively until logout). * Potential Issues: While sessions are generally persistent, issues like \"random logouts\" can occur. These are often linked to how the FlutterFlow client interacts with Supabase's refresh token management or specific Supabase configuration settings, rather than a requirement for manual session data storage by the developer. For detailed information on how Supabase handles sessions, you can refer to their official documentation on sessions: [https://supabase.com/docs/guides/auth/sessions](https://supabase.com/docs/guides/auth/sessions).

FlutterFlow applications, primarily when using Firebase Authentication, rely on the underlying authentication service (Firebase) to determine if a session has expired or become invalid. FlutterFlow itself doesn't independently track session expiration but rather interacts with Firebase's mechanisms. Here's how it generally works: 1. Firebase Issues Tokens: When a user logs in, Firebase Authentication issues two main tokens: * ID Token (JWT): A short-lived token (typically 1 hour) used to authenticate requests to Firebase services (like Firestore, Cloud Functions). * Refresh Token: A longer-lived token used to obtain new ID tokens silently without requiring the user to log in again. 2. ID Token Expiration and Refresh: As the ID token approaches its expiry, the Firebase SDK (which FlutterFlow integrates with) automatically uses the refresh token to silently fetch a new ID token in the background. This process usually happens seamlessly, keeping the user logged in without interruption for an extended period. 3. *Refresh Token Expiration/Invalidity:** If the refresh token itself expires (which can be configured in Firebase, often lasting for days or weeks) or becomes invalid (e.g., due to a password change, user being disabled by an admin, or security reasons), then Firebase can no longer provide a new ID token. At this point, subsequent authenticated requests will fail, and the FirebaseAuth.instance.currentUser might become null or operations requiring an active user session will indicate an error. 4. \"Too Long Since Last Login\" for Sensitive Operations: For highly sensitive actions like updating an email, changing a password, or deleting an account, Firebase has stricter security requirements. Even if the user's session is technically active via a refresh token, Firebase might require the user to re-authenticate* (e.g., enter their password again) if it's been \"too long since their last explicit login.\" This is to ensure the user's identity right before performing a critical action. 5. Manual Checks for Session Validity (as implemented in FlutterFlow): * The FlutterFlow app can implement checks to verify the user's authentication status. For instance, as described in the context, you can: * Check on Page Load: Implement logic on \"Page Load\" for authenticated pages to check if FirebaseAuth.instance.currentUser is still valid. * Reload User: Use await user.reload() to force Firebase to refresh the user's status. If this fails or FirebaseAuth.instance.currentUser becomes null after reloading, it indicates the session is no longer valid. * Backend Validation: For scenarios like admin-initiated forced logouts, the app can periodically communicate with a custom backend API. If the backend determines the user is no longer valid (e.g., disabled or deleted), it can return a status, prompting the FlutterFlow app to locally trigger a Logout action to clear its cached session data. In essence, FlutterFlow relies on the underlying Firebase SDK to manage token lifecycles and provides actions and the ability to add custom code to respond to the various states of a user's authentication session, including expiration or invalidation.

Do I need to store the user ID, session length etc?