The symptom to recognize

An internal panel "works" if anyone who opens the site already gets, automatically, a Firebase identity with read/write access — often because the app's bootstrap runs an unconditional login into a single shared uid, and the database Rules restrict permissions to that one uid. The login screen, in that case, is just a UI filter: it protects nothing on the data side.

The solution in three pieces

1. A Netlify login function verifies email/password server-side (never in the client) and computes role claims
2. If valid, it signs a Custom Token carrying the operator's real identity and claims
3. The client calls signInWithCustomToken() instead of a hardcoded login, and database Rules check auth.token.* instead of a fixed uid

// Gira solo lato server, mai nel bundle client
export default async function handler(req) {
  const { email, password } = await req.json();

  // 1. Rate-limit lato server: 5 tentativi, poi lockout 60s per email
  const attempts = await getAttempts(email);
  if (attempts.locked) return json({ ok: false, error: 'locked' }, 423);

  // 2. Verifica contro il nodo operatori (service account, mai nel client)
  const op = await findOperatorByEmail(email);
  const valid = op && await verifyPassword(password, op.passwordHash);
  if (!valid) { await registerFailedAttempt(email); return json({ ok: false }, 401); }

  // 3. Claim di ruolo calcolati server-side, non falsificabili dal client
  const claims = { operatore: op.chiave, admin: isAdmin(op) };
  const token = await mintCustomToken(`op_${op.chiave}`, claims);

  return json({ ok: true, token, operatore: op.chiave, admin: claims.admin });
}

// La persistenza va impostata PRIMA del sign-in, non dopo
await firebase.auth().setPersistence(
  ricordami ? firebase.auth.Auth.Persistence.LOCAL
            : firebase.auth.Auth.Persistence.SESSION
);
const res = await fetch('/.netlify/functions/operator-login', { /* ... */ });
const { token } = await res.json();
await firebase.auth().signInWithCustomToken(token);
// nessun fallback: se la function non risponde, il login fallisce e basta

On bootstrap the app no longer auto-logs in, but listens to onAuthStateChanged(): if a valid session already exists (native Firebase persistence), the UI loads directly; otherwise it shows the form. And logout must actually call signOut() — not just exit the UI, leaving the Firebase session alive in the background.

The 5-phase rollout, so no one gets locked out

Replacing the Firebase identity of an app used daily by multiple people isn't a one-shot change. Each phase is verifiable and reversible before moving to the next:

1. Phase 1 — isolated function. The login function is deployed but not yet called from anywhere in the client: zero risk, testable with a direct call.
2. Phase 2 — client with fallback. Login tries the new function first; if it doesn't respond, it falls back to the old method — no one is locked out during the transition.
3. Phase 3 — verification on real accounts. Tests with admin and non-admin users from different departments, console open hunting for permission errors.
4. Phase 4 — removing the old login. The unconditional auto-login is removed; the app waits for onAuthStateChanged(), persistence synced to "Remember me".
5. Phase 5 — deny-by-default Rules. Only after the new client has reached the whole team do the Rules move to granular claim-based permissions.

The snag to anticipate: Rules need touching mid-migration, not at the end

Changing Firebase identity at runtime immediately invalidates the permissions of anything the client had already opened under the old identity. As soon as the client starts authenticating with the new Custom Token (Phase 2), every active realtime listener is re-checked against the existing Rules — if they only authorize the old uid, everything stops working well before the migration finishes. The fix is an additive OR, safe to publish even mid-workday because it takes nothing away from anyone still on the old session:

{
  ".read":  "auth != null && (auth.uid === '[UID_CONDIVISO]' || auth.token.operatore != null)",
  ".write": "auth != null && (auth.uid === '[UID_CONDIVISO]' || auth.token.operatore != null)"
}

Phase 5 — deny-by-default Rules

With the team on the new version, the Rules move from additive to genuinely restrictive: root false by default, granular per-role permissions on every node.

{
  ".read": false, ".write": false,
  "adminData": {
    ".read":  "auth.token.operatore != null",
    ".write": "auth.token.admin === true"
  },
  "operatoriDevices": {
    "$op": { ".read": "auth.token.operatore === $op || auth.token.admin === true",
             ".write": "auth.token.operatore === $op || auth.token.admin === true" }
  },
  "chat": { "dm": { "$myKey": { ".read": "auth.token.operatore === $myKey" } } }
  // ... resto dei nodi con "auth.token.operatore != null"
}

Checklist before shipping deny-by-default Rules

• Every node read at bootstrap is accessible to all roles that go through that bootstrap, not just whoever should "see" it per app logic
• Sensitive data (password hashes, tokens, PII) lives in nodes separate from ones needed by multiple roles
• The additive (OR) transition was published and verified before tightening the final Rules
• Manual test with at least one admin and one non-admin account, console open
• A ready rollback plan: republish the additive version if something breaks

Frequently asked questions