@adonis-agora/authkit-server 0.69.0 → 0.70.0

package/build/src/host/email_identifier.js

@@ -0,0 +1,234 @@
+/**
+ * Normalização ÚNICA e CONSERVADORA do e-mail usado como identidade da conta.
+ *
+ * Faz `trim()` + `toLowerCase()` e MAIS NADA. O endereço que a pessoa digitou é a
+ * identidade dela: a lib NÃO decide que `a.b@gmail.com` e `ab@gmail.com` são a
+ * mesma pessoa, nem descarta o sub-endereço (`+tag`) que ela escolheu usar.
+ *
+ * POR QUE ISTO EXISTE: até a v0.68 o cadastro validava o e-mail com
+ * `.normalizeEmail()` do VineJS (os defaults do validator.js), que para o gmail
+ * REMOVE os pontos e o `+tag` do local part. A conta nascia com um endereço
+ * DIFERENTE do digitado (`davi.carvalho96@gmail.com` → `davicarvalho96@gmail.com`)
+ * enquanto o passo de identificador do login não normalizava NADA e buscava por
+ * igualdade exata — resultado: quem tinha ponto ou `+tag` no gmail ficava
+ * trancado do lado de fora, e, por o login ser à prova de enumeração, sem
+ * nenhuma mensagem de erro. Uma normalização só, usada nos DOIS lados, fecha a
+ * assimetria.
+ *
+ * Use em TODO ponto que grava ou busca a identidade: cadastro (com e sem senha),
+ * "esqueci a senha", troca de e-mail, criação por admin, convite de organização,
+ * import de usuários, cadastro social e o passo de identificador do login.
+ */
+export function normalizeEmailIdentifier(raw) {
+    return typeof raw === 'string' ? raw.trim().toLowerCase() : '';
+}
+// ─── Ponte de compatibilidade com a normalização LEGADA ─────────────────────
+/** Domínios do gmail (pontos e sub-endereço eram removidos do local part). */
+const GMAIL_DOMAINS = ['gmail.com', 'googlemail.com'];
+/** Domínios do iCloud (sub-endereço `+tag` removido). */
+const ICLOUD_DOMAINS = ['icloud.com', 'me.com'];
+/** Domínios do Outlook.com/Hotmail/Live (sub-endereço `+tag` removido). */
+const OUTLOOK_DOMAINS = [
+    'hotmail.at',
+    'hotmail.be',
+    'hotmail.ca',
+    'hotmail.cl',
+    'hotmail.co.il',
+    'hotmail.co.nz',
+    'hotmail.co.th',
+    'hotmail.co.uk',
+    'hotmail.com',
+    'hotmail.com.ar',
+    'hotmail.com.au',
+    'hotmail.com.br',
+    'hotmail.com.gr',
+    'hotmail.com.mx',
+    'hotmail.com.pe',
+    'hotmail.com.tr',
+    'hotmail.com.vn',
+    'hotmail.cz',
+    'hotmail.de',
+    'hotmail.dk',
+    'hotmail.es',
+    'hotmail.fr',
+    'hotmail.hu',
+    'hotmail.id',
+    'hotmail.ie',
+    'hotmail.in',
+    'hotmail.it',
+    'hotmail.jp',
+    'hotmail.kr',
+    'hotmail.lv',
+    'hotmail.my',
+    'hotmail.ph',
+    'hotmail.pt',
+    'hotmail.sa',
+    'hotmail.sg',
+    'hotmail.sk',
+    'live.be',
+    'live.co.uk',
+    'live.com',
+    'live.com.ar',
+    'live.com.mx',
+    'live.de',
+    'live.es',
+    'live.eu',
+    'live.fr',
+    'live.it',
+    'live.nl',
+    'msn.com',
+    'outlook.at',
+    'outlook.be',
+    'outlook.cl',
+    'outlook.co.il',
+    'outlook.co.nz',
+    'outlook.co.th',
+    'outlook.com',
+    'outlook.com.ar',
+    'outlook.com.au',
+    'outlook.com.br',
+    'outlook.com.gr',
+    'outlook.com.pe',
+    'outlook.com.tr',
+    'outlook.com.vn',
+    'outlook.cz',
+    'outlook.de',
+    'outlook.dk',
+    'outlook.es',
+    'outlook.fr',
+    'outlook.hu',
+    'outlook.id',
+    'outlook.ie',
+    'outlook.in',
+    'outlook.it',
+    'outlook.jp',
+    'outlook.kr',
+    'outlook.lv',
+    'outlook.my',
+    'outlook.ph',
+    'outlook.pt',
+    'outlook.sa',
+    'outlook.sg',
+    'outlook.sk',
+    'passport.com',
+];
+/** Domínios do Yahoo (sub-endereço `-tag` removido). */
+const YAHOO_DOMAINS = [
+    'rocketmail.com',
+    'yahoo.ca',
+    'yahoo.co.uk',
+    'yahoo.com',
+    'yahoo.de',
+    'yahoo.fr',
+    'yahoo.in',
+    'yahoo.it',
+    'ymail.com',
+];
+/** Domínios do Yandex (todos colapsavam em `yandex.ru`). */
+const YANDEX_DOMAINS = ['yandex.ru', 'yandex.ua', 'yandex.kz', 'yandex.com', 'yandex.by', 'ya.ru'];
+/** Remove pontos SOLTOS do local part (pontos consecutivos ficam — regra do validator.js). */
+function stripSingleDots(local) {
+    return local.replace(/\.+/g, (match) => (match.length > 1 ? match : ''));
+}
+/**
+ * Réplica da normalização LEGADA — `normalizeEmail()` do validator.js com os
+ * defaults, que é o que o `.normalizeEmail()` do VineJS aplicava no cadastro até
+ * a v0.68. Existe SÓ para reencontrar as contas que nasceram com o endereço
+ * mutilado; nada novo deve ser gravado com ela.
+ *
+ * É uma PONTE TEMPORÁRIA: quando as contas antigas tiverem sido migradas para o
+ * endereço real (ou o suficiente delas), esta função, a opção
+ * `login.legacyEmailFallback` e {@link resolveEmailIdentifier} podem sair.
+ *
+ * Retorna `null` para entradas que o validator.js também recusaria (local part
+ * vazio depois do colapso) ou que não são um endereço com `@`.
+ */
+export function legacyNormalizeEmailIdentifier(raw) {
+    const email = normalizeEmailIdentifier(raw);
+    const at = email.lastIndexOf('@');
+    if (at <= 0 || at === email.length - 1)
+        return null;
+    let local = email.slice(0, at);
+    let domain = email.slice(at + 1);
+    if (GMAIL_DOMAINS.includes(domain)) {
+        local = local.split('+')[0];
+        local = stripSingleDots(local);
+        domain = 'gmail.com';
+    }
+    else if (ICLOUD_DOMAINS.includes(domain) || OUTLOOK_DOMAINS.includes(domain)) {
+        local = local.split('+')[0];
+    }
+    else if (YAHOO_DOMAINS.includes(domain)) {
+        const parts = local.split('-');
+        local = parts.length > 1 ? parts.slice(0, -1).join('-') : parts[0];
+    }
+    else if (YANDEX_DOMAINS.includes(domain)) {
+        domain = 'yandex.ru';
+    }
+    if (!local.length)
+        return null;
+    return `${local}@${domain}`;
+}
+/**
+ * Resolve o e-mail digitado na conta correspondente.
+ *
+ * Passe o valor **CRU** (como veio do formulário, do provider ou do arquivo): a
+ * normalização acontece aqui dentro, e a forma crua é uma das candidatas da
+ * ponte. Passar um valor já normalizado apaga essa candidata e reduz o alcance
+ * da ponte às contas gravadas com o endereço mutilado.
+ *
+ * 1. Busca pela forma normalizada NOVA (trim + lowercase) — o caminho de sempre,
+ *    uma única query por igualdade (indexada).
+ * 2. Não achando, e com a ponte ligada (`login.legacyEmailFallback`, default
+ *    `true`), tenta as formas de compatibilidade:
+ *    - o endereço EXATAMENTE como digitado (só com `trim`), para as contas que
+ *      foram gravadas com maiúsculas antes desta normalização existir (import,
+ *      convite, criação por admin, provider social);
+ *    - a {@link legacyNormalizeEmailIdentifier normalização legada}, para as
+ *      contas que nasceram com o endereço mutilado.
+ *    O resultado só é aceito quando as formas de compatibilidade apontam para
+ *    EXATAMENTE UMA conta. Duas contas distintas (ex.: `Davi.C@Gmail.com` criada
+ *    pelo social E `davic@gmail.com` criada pelo cadastro legado) são um empate:
+ *    a lib não adivinha qual é a pessoa e trata como "não achei".
+ *
+ * LIMITE CONHECIDO: a ponte só alcança grafias que dá para derivar do que foi
+ * digitado. Uma conta gravada `Davi@Acme.com` é alcançada por quem digita
+ * `Davi@Acme.com` (a forma crua), mas NÃO por quem digita `davi@acme.com` — aí as
+ * três formas coincidem e só uma busca case-insensitive no store resolveria, o
+ * que exigiria varrer a tabela a cada login com e-mail desconhecido (justamente o
+ * caminho de ataque). Essas contas pedem migração do endereço gravado, não ponte.
+ *
+ * À PROVA DE ENUMERAÇÃO: nunca lança, nunca sinaliza nada para fora — quem chama
+ * segue com `account: null` exatamente como seguia antes. As buscas extras só
+ * acontecem quando as formas de compatibilidade DIFEREM da normalizada (e-mail
+ * digitado em minúsculas e sem ponto/tag → uma query só, como hoje).
+ */
+export async function resolveEmailIdentifier(store, raw, options = {}) {
+    const email = normalizeEmailIdentifier(raw);
+    const miss = {
+        email,
+        lookupEmail: email,
+        account: null,
+        viaLegacyFallback: false,
+    };
+    if (!email)
+        return miss;
+    const direct = await store.findByEmail(email);
+    if (direct)
+        return { email, lookupEmail: email, account: direct, viaLegacyFallback: false };
+    if (options.legacyFallback === false)
+        return miss;
+    const typed = typeof raw === 'string' ? raw.trim() : '';
+    const legacy = legacyNormalizeEmailIdentifier(email);
+    const candidates = [typed, legacy].filter((candidate) => !!candidate && candidate !== email);
+    const byId = new Map();
+    for (const candidate of new Set(candidates)) {
+        const found = await store.findByEmail(candidate);
+        if (found)
+            byId.set(found.id, found);
+    }
+    if (byId.size !== 1)
+        return miss;
+    const account = [...byId.values()][0];
+    return { email, lookupEmail: account.email, account, viaLegacyFallback: true };
+}

package/build/src/host/org_policy.d.ts

@@ -0,0 +1,26 @@
+/**
+ * Política EFETIVA de organizações — ponto de verdade ÚNICO das duas
+ * superfícies member-facing.
+ *
+ * O console HTML (`AccountOrgsController`) e o espelho JSON
+ * (`AccountOrgsApiController`) precisam responder à MESMA pergunta — "este
+ * usuário pode criar org? que papéis existem? quanto tempo o convite vale?" —
+ * e a resposta não está no config estático: ela é resolvida na ordem setting da
+ * org → setting global → `config.organizations` → default da lib.
+ *
+ * Mora num módulo próprio, e não dentro de um dos controllers, porque duas
+ * cópias desta resolução são exatamente como o caminho JSON acaba mais frouxo
+ * (ou mais apertado) que o formulário que ele espelha — o bug que este pacote
+ * de mudanças existe para não ter.
+ */
+import './augmentations.js';
+import type { HttpContext } from '@adonisjs/core/http';
+import { type OrganizationsPolicyConfigDefaults, type ResolvedOrganizationsPolicySetting } from './runtime_toggles.js';
+/** Defaults estáticos da política de org (config do host) — o fallback da setting. */
+export declare function orgPolicyDefaults(cfg: any): OrganizationsPolicyConfigDefaults;
+/**
+ * Política efetiva para o `orgId` (ou global, quando ausente). `settings` nulo —
+ * DB fora do ar, app sem lucid — cai no config estático, fail-safe herdado de
+ * {@link resolveEffectiveOrganizationsPolicy}.
+ */
+export declare function effectiveOrgPolicy(ctx: HttpContext, cfg: any, orgId?: string | null): Promise<ResolvedOrganizationsPolicySetting>;

package/build/src/host/org_policy.js

@@ -0,0 +1,35 @@
+/**
+ * Política EFETIVA de organizações — ponto de verdade ÚNICO das duas
+ * superfícies member-facing.
+ *
+ * O console HTML (`AccountOrgsController`) e o espelho JSON
+ * (`AccountOrgsApiController`) precisam responder à MESMA pergunta — "este
+ * usuário pode criar org? que papéis existem? quanto tempo o convite vale?" —
+ * e a resposta não está no config estático: ela é resolvida na ordem setting da
+ * org → setting global → `config.organizations` → default da lib.
+ *
+ * Mora num módulo próprio, e não dentro de um dos controllers, porque duas
+ * cópias desta resolução são exatamente como o caminho JSON acaba mais frouxo
+ * (ou mais apertado) que o formulário que ele espelha — o bug que este pacote
+ * de mudanças existe para não ter.
+ */
+import './augmentations.js';
+import { resolveRuntimeSettings } from './runtime_settings.js';
+import { resolveEffectiveOrganizationsPolicy, } from './runtime_toggles.js';
+/** Defaults estáticos da política de org (config do host) — o fallback da setting. */
+export function orgPolicyDefaults(cfg) {
+    return {
+        roles: cfg.organizations.roles,
+        allowSelfCreate: cfg.organizations.allowSelfCreate,
+        invitationTtlHours: cfg.organizations.invitationTtlHours,
+    };
+}
+/**
+ * Política efetiva para o `orgId` (ou global, quando ausente). `settings` nulo —
+ * DB fora do ar, app sem lucid — cai no config estático, fail-safe herdado de
+ * {@link resolveEffectiveOrganizationsPolicy}.
+ */
+export async function effectiveOrgPolicy(ctx, cfg, orgId) {
+    const settings = await resolveRuntimeSettings(ctx);
+    return resolveEffectiveOrganizationsPolicy(settings, orgPolicyDefaults(cfg), orgId);
+}

package/build/src/host/passkey_registration_challenge.d.ts

@@ -0,0 +1,12 @@
+/**
+ * Chave de sessão do desafio WebAuthn PENDENTE de REGISTRO de passkey.
+ *
+ * Mora num módulo próprio porque a cerimônia agora tem DOIS pares de rotas — o
+ * clássico (`/account/mfa/passkeys/{options,verify}`, que responde redirect numa
+ * navegação) e o JSON (`/account/api/mfa/passkeys/{options,verify}`, que nunca
+ * navega). Os dois precisam ler e escrever o MESMO slot: um `begin` feito por um
+ * caminho tem de poder ser finalizado pelo outro, e — mais importante — um
+ * desafio só pode existir UMA vez por sessão. Duas constantes com o mesmo valor
+ * em arquivos diferentes seriam a mesma coisa até alguém mudar uma delas.
+ */
+export declare const PASSKEY_REG_CHALLENGE_KEY = "authkit_passkey_reg_challenge";

package/build/src/host/passkey_registration_challenge.js

@@ -0,0 +1,12 @@
+/**
+ * Chave de sessão do desafio WebAuthn PENDENTE de REGISTRO de passkey.
+ *
+ * Mora num módulo próprio porque a cerimônia agora tem DOIS pares de rotas — o
+ * clássico (`/account/mfa/passkeys/{options,verify}`, que responde redirect numa
+ * navegação) e o JSON (`/account/api/mfa/passkeys/{options,verify}`, que nunca
+ * navega). Os dois precisam ler e escrever o MESMO slot: um `begin` feito por um
+ * caminho tem de poder ser finalizado pelo outro, e — mais importante — um
+ * desafio só pode existir UMA vez por sessão. Duas constantes com o mesmo valor
+ * em arquivos diferentes seriam a mesma coisa até alguém mudar uma delas.
+ */
+export const PASSKEY_REG_CHALLENGE_KEY = 'authkit_passkey_reg_challenge';

package/build/src/host/register_auth_host.js

@@ -211,6 +211,10 @@ const C = {
     apiKeys: () => import('./admin_api/api_keys_controller.js'),
     // Account self-service JSON API (session-authed, under /account/api/*).
     accountApi: () => import('./account_api/account_api_controller.js'),
+    // Espelhos JSON das ESCRITAS de org e do segundo fator — mesmos guards e
+    // mesma política do console HTML, resposta em JSON (ver os docblocks deles).
+    accountOrgsApi: () => import('./account_api/account_orgs_api_controller.js'),
+    accountMfaApi: () => import('./account_api/account_mfa_api_controller.js'),
     // API headless (Clerk-style) — host-session-authed via `headless.resolveAccountId`.
     headlessLoginMethods: () => import('./controllers/headless_login_methods_controller.js'),
 };
@@ -653,6 +657,53 @@ export function registerAuthHost(router, opts = {}) {
         router.get(`${apiBase}/orgs`, [C.accountApi, 'listOrgs']);
         router.get(`${apiBase}/orgs/invitations`, [C.accountApi, 'listOrgInvitations']);
         router.get(`${apiBase}/orgs/:id`, [C.accountApi, 'showOrg']);
+        // ─── Orgs: ESCRITA em JSON (espelho dos POSTs de formulário) ─────────
+        // SEMPRE montadas, como as leituras JSON logo acima — e NÃO amarradas ao
+        // `mountOrgs` da TELA. A tela é a UI do console; `/account/api/*` é a
+        // superfície de máquina, e quem desliga a tela é justamente o host que
+        // desenha as próprias telas e mais precisa destes endpoints. Amarrar as
+        // duas coisas tornaria o modo headless inalcançável.
+        //
+        // Desligar a tela não afrouxa nada: o que decide quem pode o quê aqui é o
+        // `accountGuard` + capability-probe do store + política efetiva
+        // (`allowSelfCreate` continua `false` por default) + papel na org — os
+        // mesmos gates do formulário, nunca a presença de uma rota HTML.
+        // ⚠️ ORDER MATTERS, de novo: segmento fixo antes de paramétrico.
+        router.post(`${apiBase}/orgs`, [C.accountOrgsApi, 'createOrg']);
+        router.post(`${apiBase}/orgs/deactivate`, [C.accountOrgsApi, 'deactivateOrg']);
+        router.post(`${apiBase}/orgs/invitations/:token/accept`, [
+            C.accountOrgsApi,
+            'acceptInvitation',
+        ]);
+        router.post(`${apiBase}/orgs/:id/activate`, [C.accountOrgsApi, 'activateOrg']);
+        router.post(`${apiBase}/orgs/:id/leave`, [C.accountOrgsApi, 'leaveOrg']);
+        router.post(`${apiBase}/orgs/:id/invitations`, [C.accountOrgsApi, 'inviteMember']);
+        router.delete(`${apiBase}/orgs/:id/invitations/:invId`, [
+            C.accountOrgsApi,
+            'revokeInvitation',
+        ]);
+        router.patch(`${apiBase}/orgs/:id/members/:accountId`, [
+            C.accountOrgsApi,
+            'updateMemberRole',
+        ]);
+        router.delete(`${apiBase}/orgs/:id/members/:accountId`, [C.accountOrgsApi, 'removeMember']);
+        // ─── Segundo fator em JSON (espelho do console de MFA) ───────────────
+        // Mesma decisão das de org: superfície de máquina, montada sempre. Sem a
+        // capacidade de MFA no store, cada handler responde 422
+        // `capability_unsupported` — capability-probed, como o resto do
+        // `/account/api/*`.
+        router.post(`${apiBase}/mfa/totp/enroll`, [C.accountMfaApi, 'enrollTotp']);
+        // THROTTLE no confirm: o código TOTP é adivinhável (6 dígitos), e o
+        // `accountGuard` sozinho só exige uma sessão viva — que quem está
+        // tentando adivinhar tem. Bucket de SUDO (por IP): mesma natureza —
+        // usuário autenticado reprovando um fator —, contagem separada do login.
+        // O form clássico não tem isto; o JSON fica MAIS apertado, que é a única
+        // direção em que os dois caminhos podem divergir.
+        withSudo(router.post(`${apiBase}/mfa/totp/confirm`, [C.accountMfaApi, 'confirmTotp']));
+        router.post(`${apiBase}/mfa/totp/disable`, [C.accountMfaApi, 'disableTotp']);
+        router.post(`${apiBase}/mfa/recovery-codes`, [C.accountMfaApi, 'regenerateRecoveryCodes']);
+        router.post(`${apiBase}/mfa/passkeys/options`, [C.accountMfaApi, 'passkeyRegisterOptions']);
+        router.post(`${apiBase}/mfa/passkeys/verify`, [C.accountMfaApi, 'passkeyRegisterVerify']);
     })
         .use([accountGuard]);
     // API headless (Clerk-style) — montada fora do `accountGuard` (não depende da

package/build/src/host/sudo_mode.d.ts

@@ -108,6 +108,23 @@ export declare function markSudo(ctx: HttpContext): void;
  * @returns `true` se o sudo está ativo (dentro da graça); `false` caso contrário.
  */
 export declare function isSudoActive(ctx: HttpContext, graceMinutes: number): boolean;
+/**
+ * A DECISÃO de sudo, sem efeito colateral nenhum na resposta: `true` quando a
+ * requisição pode seguir, `false` quando o usuário precisa reconfirmar a
+ * identidade.
+ *
+ * Existe porque há DUAS formas de recusar a mesma coisa. O console HTML
+ * redireciona para `/account/confirm` (`requireSudo`); o espelho JSON de
+ * `/account/api/*` responde `403 { error: { code: 'sudo_required' } }`, porque
+ * uma SPA que recebe uma página de login onde esperava JSON não tem como
+ * reagir. A POLÍTICA — toggle `sudo_mode`, janela de graça, vinculação à conta,
+ * fail-safe da setting e fail-closed da marca — tem de ser UMA só: duas cópias
+ * dela são como o caminho JSON acaba mais frouxo que o formulário.
+ *
+ * Toda a discussão de fail-safe × fail-closed do {@link requireSudo} vale aqui
+ * sem mudança: é literalmente o mesmo código.
+ */
+export declare function isSudoSatisfied(ctx: HttpContext, settings: SettingsCapability | null): Promise<boolean>;
 /**
  * Guard de sudo mode. Verifica se a confirmação de identidade está ativa e
  * dentro da janela de graça. Se estiver, retorna `true`. Se não, redireciona

package/build/src/host/sudo_mode.js

@@ -146,6 +146,36 @@ export function isSudoActive(ctx, graceMinutes) {
     const graceMs = graceMinutes * 60 * 1000;
     return Date.now() - sudoAt <= graceMs;
 }
+/**
+ * A DECISÃO de sudo, sem efeito colateral nenhum na resposta: `true` quando a
+ * requisição pode seguir, `false` quando o usuário precisa reconfirmar a
+ * identidade.
+ *
+ * Existe porque há DUAS formas de recusar a mesma coisa. O console HTML
+ * redireciona para `/account/confirm` (`requireSudo`); o espelho JSON de
+ * `/account/api/*` responde `403 { error: { code: 'sudo_required' } }`, porque
+ * uma SPA que recebe uma página de login onde esperava JSON não tem como
+ * reagir. A POLÍTICA — toggle `sudo_mode`, janela de graça, vinculação à conta,
+ * fail-safe da setting e fail-closed da marca — tem de ser UMA só: duas cópias
+ * dela são como o caminho JSON acaba mais frouxo que o formulário.
+ *
+ * Toda a discussão de fail-safe × fail-closed do {@link requireSudo} vale aqui
+ * sem mudança: é literalmente o mesmo código.
+ */
+export async function isSudoSatisfied(ctx, settings) {
+    try {
+        const cfg = settings ? await resolveEffectiveSudoMode(settings) : SUDO_MODE_DEFAULTS;
+        if (!cfg.enabled)
+            return true;
+        return isSudoActive(ctx, cfg.graceMinutes);
+    }
+    catch {
+        // FAIL-SAFE: erro ao resolver a setting → deixa passar. Disponibilidade, não
+        // identidade — ver o docblock de `requireSudo` para o porquê de isto NÃO
+        // contradizer o fail-closed de `isSudoActive`.
+        return true;
+    }
+}
 /**
  * Guard de sudo mode. Verifica se a confirmação de identidade está ativa e
  * dentro da janela de graça. Se estiver, retorna `true`. Se não, redireciona
@@ -202,19 +232,8 @@ export function isSudoActive(ctx, graceMinutes) {
  * postura é fail-closed de novo.
  */
 export async function requireSudo(ctx, settings) {
-    try {
-        const cfg = settings ? await resolveEffectiveSudoMode(settings) : SUDO_MODE_DEFAULTS;
-        if (!cfg.enabled)
-            return true;
-        if (isSudoActive(ctx, cfg.graceMinutes))
-            return true;
-    }
-    catch {
-        // FAIL-SAFE: erro ao resolver a setting → deixa passar. Disponibilidade, não
-        // identidade — ver o docblock acima para o porquê de isto NÃO contradizer o
-        // fail-closed de `isSudoActive`.
+    if (await isSudoSatisfied(ctx, settings))
         return true;
-    }
     // Fora da graça: redireciona para confirmação.
     const rawUrl = ctx.request.url?.() ?? '';
     const qs = ctx.request.parsedUrl?.search ?? '';