Authentication

Relevant source files

The following files were used as context for generating this wiki page:

• app/auth/login.tsx
• app/auth/register.tsx
• app/auth/forgot-password.tsx
• contexts/AuthContext.tsx
• scripts/create-auth-users.js
• scripts/check-specific-user.js
• FIXES-APLICADOS.md
• REPORTE-EJECUCION-PRUEBAS.md
• supabase/setup-instructions.md
• DEPLOY-NETLIFY.md

The authentication system for the ElmecV2 application provides secure access for users, agents, and administrators. It is built using Supabase as the backend service, handling user identity, session management, and secure data access. The system's core is a centralized AuthContext that manages the application's authentication state, making it available to all components.

The primary authentication method is email and password. The system also includes mechanisms for session persistence, automatic token refresh, and role-based access control enforced by Supabase's Row Level Security (RLS). While screens for user registration and password recovery exist, the main tested and functional flow revolves around user login and logout.

Architecture Overview

The authentication architecture is centered around the AuthContext which acts as a bridge between the UI components and the Supabase backend. UI screens trigger authentication actions (like signIn), the context processes them using the Supabase client, and the application state updates reactively based on Supabase's onAuthStateChange events.

This diagram illustrates the high-level architecture of the authentication system.

Core Components

AuthContext

The AuthContext is the single source of truth for authentication within the application. It wraps the main application layout and provides the authentication state and functions to all child components.

Sources: contexts/AuthContext.tsx

Key Responsibilities:

• State Management: Holds the session, user data, and a boolean isAuthenticated flag.
• Session Synchronization: Uses Supabase's onAuthStateChange listener to automatically update the application's state when the user logs in, logs out, or the session token is refreshed.
• Action Dispatching: Exposes functions for signing in and signing out.

Provided State and Functions:

Name	Type	Description
session	Session | null	The current Supabase session object, containing the access token.
user	User | null	The authenticated user's profile data from the users table.
isAuthenticated	boolean	A flag indicating if a user is currently authenticated.
signIn	function	Function to log in a user with email and password.
signOut	function	Function to log out the current user.
isLoading	boolean	A flag indicating if the initial session check is in progress.

Sources: contexts/AuthContext.tsx:21-31

Initial Routing (app/index.tsx)

The root index.tsx file is responsible for directing the user to the correct initial screen. It consumes the isLoading and isAuthenticated state from AuthContext to decide where to navigate.

Logic Flow:

1. If isLoading is true, a <LoadingScreen /> is displayed.
2. If isAuthenticated is true, the user is redirected to the main application via <Redirect href="/(tabs)" />.
3. If isAuthenticated is false, the user is redirected to the login screen via <Redirect href="/auth" />.

Sources: FIXES-APLICADOS.md

Authentication Screens

The application includes several screens under the app/auth/ directory to handle different authentication flows.

• login.tsx: The primary entry point for unauthenticated users. It provides a form for email and password input and handles the call to the signIn function from AuthContext. It features form validation and displays loading indicators and error alerts. The UI includes the ELMEC logo and corporate color palette.
  Sources: app/auth/login.tsx, TEST_REPORT.md
• register.tsx: A placeholder screen for user registration. The functionality is not fully implemented or integrated into the main application flow.
  Sources: app/auth/register.tsx
• forgot-password.tsx: A placeholder screen for password recovery. According to test reports, this feature is not implemented.
  Sources: app/auth/forgot-password.tsx, REPORTE-EJECUCION-PRUEBAS.md

Authentication Flows

Login Flow

The login process is initiated from the login.tsx screen and orchestrated by the AuthContext.

This sequence diagram shows the steps involved in a user login.

Logout Flow

The logout process is simpler and involves clearing the session from Supabase, which in turn updates the AuthContext state.

User Provisioning and Management

For the demo, users are not expected to register through the app. Instead, a Node.js script is provided to create Supabase Auth accounts for pre-existing user profiles in the public.users table.

Sources: scripts/create-auth-users.js, scripts/check-specific-user.js

create-auth-users.js Script

This script is essential for setting up the demo environment. It reads user profiles from the users table (filtered by empresa = 'ELMEC') and creates corresponding accounts in Supabase Auth.

Script Logic:

1. Connect to Supabase using the SERVICE_ROLE_KEY.
2. Fetch all user profiles from the public.users table where empresa is 'ELMEC'.
3. For each profile:
   a. Check if an Auth user already exists with that email.
   b. If not, create a new Auth user using supabase.auth.admin.createUser(). A default temporary password is assigned, and the email is pre-confirmed.
   c. User metadata (name, role, etc.) from the users table is copied to the user_metadata field in auth.users.
   d. The id of the profile in the public.users table is updated to match the new id from auth.users, linking the two records.

This flowchart visualizes the user provisioning process.

Demo User Credentials

The following credentials are available for testing the application after deployment.

Role	Email	Password
Admin	i.pineda@elmec.com.mx	Elmec2024!Admin
Agent	j.gonzalez@elmec.com.mx	Elmec2024!Agent
Client	cliente@gmail.com	Elmec2024!Client

Sources: DEPLOY-NETLIFY.md, supabase/setup-instructions.md

Data Models

The system uses two main tables for user data: the private auth.users table managed by Supabase Auth and a public users table for application-specific profile information.

This ER diagram shows the relationship between the two user tables.

The id in public.users is explicitly updated by the create-auth-users.js script to match the id from auth.users, establishing a one-to-one relationship.

Sources: scripts/create-auth-users.js:73-79, scripts/check-specific-user.js:33-41