Skip to main content
The validate_user.js module exports four functions that handle different aspects of user verification across the TMT Platform. Use these after a user authenticates to confirm they have the correct access level before allowing them into protected areas.

Functions overview

FunctionTransportPurpose
validate_user_platformHTTP (onRequest)Check that an email exists in a specific collection
validate_user_typeHTTP (onRequest)Check that an email exists with a specific account_type
setSessionIdCallable (onCall)Store a session ID in Firestore and as a custom claim
validate_user_emailHTTP (onRequest)Confirm a collaborator’s email and activate their account

validate_user_platform

Checks whether a user with a given email exists in a platform collection. Use this to verify that an authenticated user belongs to the platform before granting access.

Endpoint

POST https://<region>-<project>.cloudfunctions.net/validate_user_platform

Request

data.platform
string
required
Firestore collection name to search in. One of u_clients, u_collaborators, or u_staff.
data.email
string
required
Email address to look up.
{
  "data": {
    "platform": "u_clients",
    "email": "[email protected]"
  }
}

Response

User found:
{
  "message": "User allowed",
  "status": 200,
  "data": { "valido": true }
}
User not found:
{
  "message": "User not allowed",
  "status": 400,
  "data": { "valido": false }
}
The function queries the collection for any document where email equals the provided value. If a matching document exists, it responds with valido: true. If the snapshot is empty, it responds with valido: false.

validate_user_type

Checks whether a user with a given email exists in a collection and has a specific account_type. Use this when different account types within the same collection have different access levels.

Endpoint

POST https://<region>-<project>.cloudfunctions.net/validate_user_type

Request

data.platform
string
required
Firestore collection name to search in.
data.email
string
required
Email address to look up.
data.account_type
string
required
The account_type value the user must have (for example, admin, collaborator).
{
  "data": {
    "platform": "u_collaborators",
    "email": "[email protected]",
    "account_type": "collaborator"
  }
}

Response

User found with matching type:
{
  "message": "User allowed",
  "status": 200,
  "data": { "valido": true }
}
User not found or type mismatch:
{
  "message": "User not allowed",
  "status": 400,
  "data": { "valido": false }
}

setSessionId

Stores a session ID for an authenticated user in both Firestore (under users/{uid}) and as a Firebase custom claim. Use this to implement single-session enforcement — when a new session is set, existing sessions with a different sessionId can be rejected.
This function uses the Firebase Callable SDK (onCall), not a plain HTTP request. Call it from a Firebase client SDK, not with a raw HTTP client.

Callable function invocation (JavaScript)

import { getFunctions, httpsCallable } from "firebase/functions";

const functions = getFunctions();
const setSessionId = httpsCallable(functions, "setSessionId");

const result = await setSessionId({ sessionId: "sess_abc123" });
console.log(result.data); // { success: true }

Request data

sessionId
string
required
A unique identifier for the current session. Generate this on your client after the user signs in.

What it does

  1. Verifies the caller is authenticated via Firebase Auth. Throws unauthenticated if not.
  2. Writes { sessionId } to users/{uid} in Firestore (merges with existing data).
  3. Sets { sessionId } as a custom claim on the Firebase Auth user via setCustomUserClaims.

Response

{ "success": true }
Calling setSessionId overwrites any previously stored sessionId. Clients holding tokens with an old sessionId claim will be considered invalid once your backend starts enforcing session checks.

validate_user_email

Verifies that a collaborator’s email address matches what is stored in their u_collaborators document and, if it matches, sets their status to true. Use this as the final step in a collaborator email confirmation flow.

Endpoint

POST https://<region>-<project>.cloudfunctions.net/validate_user_email

Request

data.uid_user
string
required
The UID of the collaborator document in u_collaborators.
data.email
string
required
The email address to verify against the stored record.
{
  "data": {
    "uid_user": "def456uvw",
    "email": "[email protected]"
  }
}

What it does

  1. Validates that both uid_user and email are present. Returns 400 if either is missing.
  2. Fetches the document at u_collaborators/{uid_user}. Returns 404 if not found.
  3. Compares the provided email against userData.email. Returns 403 if they do not match.
  4. Updates status to true on the document. Returns 200 on success.

Response

Success (200):
{
  "data": {
    "message": "Usuario validado y actualizado correctamente.",
    "status": 200
  }
}
Missing fields (400):
{
  "data": {
    "message": "El UID y el correo son obligatorios.",
    "status": 400
  }
}
User not found (404):
{
  "data": {
    "message": "Usuario no encontrado.",
    "status": 404
  }
}
Email mismatch (403):
{
  "data": {
    "message": "El correo electrónico no coincide.",
    "status": 403
  }
}
Server error (500):
{
  "data": {
    "message": "Error interno del servidor.",
    "status": 500
  }
}
This function only operates on the u_collaborators collection. It does not validate clients or staff accounts.

Build docs developers (and LLMs) love