@adonis-agora/authkit-server 0.45.0 → 0.46.0

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

@@ -9,7 +9,9 @@
  *   - `enabled`:      habilita/desabilita o sudo mode. Default: true.
  *   - `graceMinutes`: janela de graça em minutos. Default: 15.
  *
- * Chave de sessão: `authkit_sudo_at` (timestamp ms).
+ * Chaves de sessão: `authkit_sudo_at` (timestamp ms) + `authkit_sudo_account`
+ * (a conta que confirmou). As duas juntas são a marca — ver
+ * `SUDO_ACCOUNT_SESSION_KEY`.
  */
 import type { HttpContext } from '@adonisjs/core/http';
 import type { SettingsCapability } from './runtime_settings.js';
@@ -24,17 +26,84 @@ export interface ResolvedSudoModeSetting {
 export declare const SUDO_MODE_DEFAULTS: ResolvedSudoModeSetting;
 /**
  * Resolve a setting `sudo_mode` em runtime (fail-safe).
+ *
+ * FAIL-SAFE, e de propósito: setting ausente, malformada ou store indisponível
+ * caem em `SUDO_MODE_DEFAULTS` em vez de lançar. A pergunta que esta função
+ * responde é de DISPONIBILIDADE — "o toggle de sudo mode está ligado, e com que
+ * janela de graça?" —, não de identidade. Um erro aqui não é sinal de credencial
+ * suspeita; é o store de settings fora do ar.
+ *
+ * Note que o default é `enabled: true`: o fail-safe não desliga o sudo mode, ele
+ * mantém a política default LIGADA. Quem decide o que fazer com uma sessão sem
+ * sudo continua sendo `isSudoActive` (fail-CLOSED). Ver o docblock de
+ * `requireSudo` para a assimetria completa entre as duas posturas — ela é
+ * escolha, não descuido.
  */
 export declare function resolveEffectiveSudoMode(settings: SettingsCapability): Promise<ResolvedSudoModeSetting>;
 /** Chave da sessão Adonis que registra quando o sudo foi confirmado. */
 export declare const SUDO_SESSION_KEY = "authkit_sudo_at";
 /**
- * Registra o timestamp de confirmação de sudo na sessão (NOW).
- * Chamar após o usuário confirmar sua identidade (senha ou passkey).
+ * Conta que CONFIRMOU o sudo registrado em `SUDO_SESSION_KEY`.
+ *
+ * Por que existe: o timestamp sozinho é uma marca de "alguém confirmou a
+ * identidade nesta sessão há pouco" — sem dizer QUEM. E a sessão sobrevive à
+ * troca de conta: o `regenerate()` só troca o id do cookie e MIGRA os dados
+ * (é o invariante descrito no M6 de `account_session_controller.ts`). Sem esta
+ * vinculação, todo caminho que troca a conta da sessão TRANSFERE o sudo junto:
+ *
+ *   - impersonation: um admin que confirmou sudo sobre a PRÓPRIA conta passava
+ *     a ter sudo sobre a conta personificada (`startImpersonation`); e o sudo
+ *     obtido ENQUANTO personificava voltava a valer sobre a conta do admin
+ *     (`stopImpersonation`);
+ *   - navegador compartilhado: A confirma sudo, faz logout, B loga, e B herda
+ *     a graça de A (hoje mascarado porque `login()` chama `markSudo` logo em
+ *     seguida — acidente, não desenho).
+ *
+ * A garantia vira ESTRUTURAL em vez de depender de alguém lembrar de limpar a
+ * marca em toda transição futura: qualquer troca de conta, inclusive as que
+ * ainda não existem, invalida o sudo sem tocar em código novo.
+ *
+ * Chave SEPARADA de propósito (mesma decisão de
+ * `CONFIRM_PASSKEY_CHALLENGE_ACCOUNT_KEY`): o valor de `SUDO_SESSION_KEY` é um
+ * número e isso é contratual — está pinado em
+ * `tests/host/account_confirm_controller.spec.ts` com `assert.isNumber`. Então
+ * a vinculação é ADITIVA, em vez de mudar a forma do valor pinado para
+ * `{ at, accountId }`. Bônus: as assinaturas públicas de `markSudo` /
+ * `isSudoActive` (exportadas em `index.ts`) ficam intactas.
+ */
+export declare const SUDO_ACCOUNT_SESSION_KEY = "authkit_sudo_account";
+/**
+ * Registra o timestamp de confirmação de sudo na sessão (NOW), VINCULADO à
+ * conta atual da sessão. Chamar após o usuário confirmar sua identidade.
+ *
+ * Sem conta na sessão não há a quem vincular: grava o timestamp (contrato
+ * pinado) e APAGA qualquer vinculação anterior, para que a marca não fique
+ * herdando o dono antigo. O resultado é uma marca órfã, que `isSudoActive`
+ * recusa (fail-closed).
+ *
+ * @deprecated Para conceder sudo, use `completeSudo(sudoContextFrom(ctx), id)`.
+ * `markSudo` grava a marca e nada mais: não registra o audit `sudo.confirmed`,
+ * não lembra o método usado e não redireciona para o `return_to`. Um host que a
+ * chame direto — o caminho natural no callback de `oidcStepUp`, antes de
+ * `completeSudo` ser público — concede privilégio sem deixar rastro nenhum.
+ * Continua exportada porque o login primário do próprio pacote a usa (ver o
+ * CHANGELOG desta versão) e porque removê-la seria breaking; o uso legítimo
+ * restante é ler/limpar a marca em fluxos que não são confirmação de
+ * identidade.
  */
 export declare function markSudo(ctx: HttpContext): void;
 /**
- * Verifica se o sudo está ativo (dentro da janela de graça).
+ * Verifica se o sudo está ativo: dentro da janela de graça E confirmado PELA
+ * CONTA que está logada agora.
+ *
+ * FAIL-CLOSED na vinculação (mesma postura do challenge de passkey): marca sem
+ * `accountId`, ou com um `accountId` que não bate com a conta atual da sessão,
+ * é recusada. Isso inclui sessões que já estavam vivas antes deste deploy — elas
+ * perdem o sudo e reconfirmam, que é o lado seguro do trade-off.
+ *
+ * Esta postura é o OPOSTO do fail-safe de `requireSudo`, e as duas estão certas:
+ * aqui a pergunta é "esta marca é minha?" (identidade), lá é "o toggle está
+ * ligado?" (disponibilidade). O docblock de `requireSudo` desenvolve a distinção.
  *
  * @returns `true` se o sudo está ativo (dentro da graça); `false` caso contrário.
  */
@@ -50,7 +119,48 @@ export declare function isSudoActive(ctx: HttpContext, graceMinutes: number): bo
  * if (result !== true) return result
  * ```
  *
- * FAIL-SAFE: qualquer erro lê settings → retorna `true` (deixa passar).
- * Quando `sudo_mode.enabled = false`, sempre retorna `true`.
+ * FAIL-SAFE: qualquer erro ao resolver a setting → retorna `true` (deixa
+ * passar). Quando `sudo_mode.enabled = false`, sempre retorna `true`.
+ *
+ * ---
+ *
+ * POR QUE ESTE FAIL-SAFE CONVIVE COM O FAIL-CLOSED DAS VINCULAÇÕES.
+ *
+ * Lendo este arquivo (e os vizinhos) aparecem duas posturas OPOSTAS diante de
+ * uma situação anômala, e isso é deliberado — não é um dos dois lados por
+ * consertar. Quem "harmonizar" as duas quebra alguma coisa:
+ *
+ *   - FAIL-CLOSED nas vinculações à conta: a marca de sudo
+ *     (`SUDO_ACCOUNT_SESSION_KEY` em `isSudoActive`), o challenge de passkey do
+ *     confirm e o token pendente do magic link de sudo. Todas recusam quando a
+ *     vinculação falta ou não bate.
+ *   - FAIL-SAFE aqui, ao resolver a setting `sudo_mode`.
+ *
+ * A diferença não é de rigor, é de PERGUNTA:
+ *
+ *   - As vinculações perguntam **"esta credencial é minha?"**. É IDENTIDADE. Uma
+ *     resposta duvidosa é indistinguível de uma resposta negativa — uma marca
+ *     sem dono pode ser a marca de outra conta que sobreviveu à troca de sessão.
+ *     Deixar passar concede privilégio a quem talvez não o tenha, e o custo do
+ *     erro é escalação. Identidade duvidosa é recusada; o usuário reconfirma,
+ *     que é barato.
+ *   - Este fail-safe pergunta **"o toggle de sudo mode está ligado?"**. É
+ *     DISPONIBILIDADE, uma questão de configuração, e a resposta não diz nada
+ *     sobre quem é o usuário. Quem chega aqui já passou pelo `accountGuard`:
+ *     tem sessão de conta viva e autenticada.
+ *
+ * Inverter ESTE lado para fail-closed transformaria uma indisponibilidade do
+ * store de settings (BD fora do ar, timeout, migração em curso) num lockout
+ * TOTAL: todo mundo, simultaneamente, trancado fora da própria área de conta —
+ * inclusive fora dos caminhos de recuperação. E o ataque que isso evitaria
+ * exige que o atacante já tenha uma sessão autenticada da vítima E consiga
+ * derrubar o store de settings no mesmo instante. Trocar uma falha rara e
+ * condicionada por uma indisponibilidade certa e generalizada é o pior dos dois
+ * negócios.
+ *
+ * O fail-safe também é ESTREITO: ele só decide se a BARREIRA roda. Ele não
+ * concede sudo, não fabrica marca nenhuma e não mexe em vinculação. Se a setting
+ * resolve normalmente, a decisão volta inteira para `isSudoActive` — e lá a
+ * postura é fail-closed de novo.
  */
 export declare function requireSudo(ctx: HttpContext, settings: SettingsCapability | null): Promise<true | unknown>;

package/build/src/host/sudo_mode.js

@@ -9,8 +9,11 @@
  *   - `enabled`:      habilita/desabilita o sudo mode. Default: true.
  *   - `graceMinutes`: janela de graça em minutos. Default: 15.
  *
- * Chave de sessão: `authkit_sudo_at` (timestamp ms).
+ * Chaves de sessão: `authkit_sudo_at` (timestamp ms) + `authkit_sudo_account`
+ * (a conta que confirmou). As duas juntas são a marca — ver
+ * `SUDO_ACCOUNT_SESSION_KEY`.
  */
+import { ACCOUNT_SESSION_KEY } from './middleware/account_auth.js';
 import { SETTING_KEYS } from './runtime_toggles.js';
 export const SUDO_MODE_DEFAULTS = {
     enabled: true,
@@ -18,6 +21,18 @@ export const SUDO_MODE_DEFAULTS = {
 };
 /**
  * Resolve a setting `sudo_mode` em runtime (fail-safe).
+ *
+ * FAIL-SAFE, e de propósito: setting ausente, malformada ou store indisponível
+ * caem em `SUDO_MODE_DEFAULTS` em vez de lançar. A pergunta que esta função
+ * responde é de DISPONIBILIDADE — "o toggle de sudo mode está ligado, e com que
+ * janela de graça?" —, não de identidade. Um erro aqui não é sinal de credencial
+ * suspeita; é o store de settings fora do ar.
+ *
+ * Note que o default é `enabled: true`: o fail-safe não desliga o sudo mode, ele
+ * mantém a política default LIGADA. Quem decide o que fazer com uma sessão sem
+ * sudo continua sendo `isSudoActive` (fail-CLOSED). Ver o docblock de
+ * `requireSudo` para a assimetria completa entre as duas posturas — ela é
+ * escolha, não descuido.
  */
 export async function resolveEffectiveSudoMode(settings) {
     try {
@@ -44,14 +59,74 @@ export async function resolveEffectiveSudoMode(settings) {
 /** Chave da sessão Adonis que registra quando o sudo foi confirmado. */
 export const SUDO_SESSION_KEY = 'authkit_sudo_at';
 /**
- * Registra o timestamp de confirmação de sudo na sessão (NOW).
- * Chamar após o usuário confirmar sua identidade (senha ou passkey).
+ * Conta que CONFIRMOU o sudo registrado em `SUDO_SESSION_KEY`.
+ *
+ * Por que existe: o timestamp sozinho é uma marca de "alguém confirmou a
+ * identidade nesta sessão há pouco" — sem dizer QUEM. E a sessão sobrevive à
+ * troca de conta: o `regenerate()` só troca o id do cookie e MIGRA os dados
+ * (é o invariante descrito no M6 de `account_session_controller.ts`). Sem esta
+ * vinculação, todo caminho que troca a conta da sessão TRANSFERE o sudo junto:
+ *
+ *   - impersonation: um admin que confirmou sudo sobre a PRÓPRIA conta passava
+ *     a ter sudo sobre a conta personificada (`startImpersonation`); e o sudo
+ *     obtido ENQUANTO personificava voltava a valer sobre a conta do admin
+ *     (`stopImpersonation`);
+ *   - navegador compartilhado: A confirma sudo, faz logout, B loga, e B herda
+ *     a graça de A (hoje mascarado porque `login()` chama `markSudo` logo em
+ *     seguida — acidente, não desenho).
+ *
+ * A garantia vira ESTRUTURAL em vez de depender de alguém lembrar de limpar a
+ * marca em toda transição futura: qualquer troca de conta, inclusive as que
+ * ainda não existem, invalida o sudo sem tocar em código novo.
+ *
+ * Chave SEPARADA de propósito (mesma decisão de
+ * `CONFIRM_PASSKEY_CHALLENGE_ACCOUNT_KEY`): o valor de `SUDO_SESSION_KEY` é um
+ * número e isso é contratual — está pinado em
+ * `tests/host/account_confirm_controller.spec.ts` com `assert.isNumber`. Então
+ * a vinculação é ADITIVA, em vez de mudar a forma do valor pinado para
+ * `{ at, accountId }`. Bônus: as assinaturas públicas de `markSudo` /
+ * `isSudoActive` (exportadas em `index.ts`) ficam intactas.
+ */
+export const SUDO_ACCOUNT_SESSION_KEY = 'authkit_sudo_account';
+/**
+ * Registra o timestamp de confirmação de sudo na sessão (NOW), VINCULADO à
+ * conta atual da sessão. Chamar após o usuário confirmar sua identidade.
+ *
+ * Sem conta na sessão não há a quem vincular: grava o timestamp (contrato
+ * pinado) e APAGA qualquer vinculação anterior, para que a marca não fique
+ * herdando o dono antigo. O resultado é uma marca órfã, que `isSudoActive`
+ * recusa (fail-closed).
+ *
+ * @deprecated Para conceder sudo, use `completeSudo(sudoContextFrom(ctx), id)`.
+ * `markSudo` grava a marca e nada mais: não registra o audit `sudo.confirmed`,
+ * não lembra o método usado e não redireciona para o `return_to`. Um host que a
+ * chame direto — o caminho natural no callback de `oidcStepUp`, antes de
+ * `completeSudo` ser público — concede privilégio sem deixar rastro nenhum.
+ * Continua exportada porque o login primário do próprio pacote a usa (ver o
+ * CHANGELOG desta versão) e porque removê-la seria breaking; o uso legítimo
+ * restante é ler/limpar a marca em fluxos que não são confirmação de
+ * identidade.
  */
 export function markSudo(ctx) {
+    const accountId = ctx.session.get(ACCOUNT_SESSION_KEY);
     ctx.session.put(SUDO_SESSION_KEY, Date.now());
+    if (accountId)
+        ctx.session.put(SUDO_ACCOUNT_SESSION_KEY, accountId);
+    else
+        ctx.session.forget(SUDO_ACCOUNT_SESSION_KEY);
 }
 /**
- * Verifica se o sudo está ativo (dentro da janela de graça).
+ * Verifica se o sudo está ativo: dentro da janela de graça E confirmado PELA
+ * CONTA que está logada agora.
+ *
+ * FAIL-CLOSED na vinculação (mesma postura do challenge de passkey): marca sem
+ * `accountId`, ou com um `accountId` que não bate com a conta atual da sessão,
+ * é recusada. Isso inclui sessões que já estavam vivas antes deste deploy — elas
+ * perdem o sudo e reconfirmam, que é o lado seguro do trade-off.
+ *
+ * Esta postura é o OPOSTO do fail-safe de `requireSudo`, e as duas estão certas:
+ * aqui a pergunta é "esta marca é minha?" (identidade), lá é "o toggle está
+ * ligado?" (disponibilidade). O docblock de `requireSudo` desenvolve a distinção.
  *
  * @returns `true` se o sudo está ativo (dentro da graça); `false` caso contrário.
  */
@@ -59,6 +134,14 @@ export function isSudoActive(ctx, graceMinutes) {
     const sudoAt = ctx.session.get(SUDO_SESSION_KEY);
     if (!sudoAt)
         return false;
+    // A vinculação é checada ANTES da graça: uma marca de outra conta não é
+    // "sudo expirado", é sudo que nunca valeu aqui.
+    const sudoAccountId = ctx.session.get(SUDO_ACCOUNT_SESSION_KEY);
+    if (!sudoAccountId)
+        return false;
+    const currentAccountId = ctx.session.get(ACCOUNT_SESSION_KEY);
+    if (!currentAccountId || sudoAccountId !== currentAccountId)
+        return false;
     const graceMs = graceMinutes * 60 * 1000;
     return Date.now() - sudoAt <= graceMs;
 }
@@ -73,8 +156,49 @@ export function isSudoActive(ctx, graceMinutes) {
  * if (result !== true) return result
  * ```
  *
- * FAIL-SAFE: qualquer erro lê settings → retorna `true` (deixa passar).
- * Quando `sudo_mode.enabled = false`, sempre retorna `true`.
+ * FAIL-SAFE: qualquer erro ao resolver a setting → retorna `true` (deixa
+ * passar). Quando `sudo_mode.enabled = false`, sempre retorna `true`.
+ *
+ * ---
+ *
+ * POR QUE ESTE FAIL-SAFE CONVIVE COM O FAIL-CLOSED DAS VINCULAÇÕES.
+ *
+ * Lendo este arquivo (e os vizinhos) aparecem duas posturas OPOSTAS diante de
+ * uma situação anômala, e isso é deliberado — não é um dos dois lados por
+ * consertar. Quem "harmonizar" as duas quebra alguma coisa:
+ *
+ *   - FAIL-CLOSED nas vinculações à conta: a marca de sudo
+ *     (`SUDO_ACCOUNT_SESSION_KEY` em `isSudoActive`), o challenge de passkey do
+ *     confirm e o token pendente do magic link de sudo. Todas recusam quando a
+ *     vinculação falta ou não bate.
+ *   - FAIL-SAFE aqui, ao resolver a setting `sudo_mode`.
+ *
+ * A diferença não é de rigor, é de PERGUNTA:
+ *
+ *   - As vinculações perguntam **"esta credencial é minha?"**. É IDENTIDADE. Uma
+ *     resposta duvidosa é indistinguível de uma resposta negativa — uma marca
+ *     sem dono pode ser a marca de outra conta que sobreviveu à troca de sessão.
+ *     Deixar passar concede privilégio a quem talvez não o tenha, e o custo do
+ *     erro é escalação. Identidade duvidosa é recusada; o usuário reconfirma,
+ *     que é barato.
+ *   - Este fail-safe pergunta **"o toggle de sudo mode está ligado?"**. É
+ *     DISPONIBILIDADE, uma questão de configuração, e a resposta não diz nada
+ *     sobre quem é o usuário. Quem chega aqui já passou pelo `accountGuard`:
+ *     tem sessão de conta viva e autenticada.
+ *
+ * Inverter ESTE lado para fail-closed transformaria uma indisponibilidade do
+ * store de settings (BD fora do ar, timeout, migração em curso) num lockout
+ * TOTAL: todo mundo, simultaneamente, trancado fora da própria área de conta —
+ * inclusive fora dos caminhos de recuperação. E o ataque que isso evitaria
+ * exige que o atacante já tenha uma sessão autenticada da vítima E consiga
+ * derrubar o store de settings no mesmo instante. Trocar uma falha rara e
+ * condicionada por uma indisponibilidade certa e generalizada é o pior dos dois
+ * negócios.
+ *
+ * O fail-safe também é ESTREITO: ele só decide se a BARREIRA roda. Ele não
+ * concede sudo, não fabrica marca nenhuma e não mexe em vinculação. Se a setting
+ * resolve normalmente, a decisão volta inteira para `isSudoActive` — e lá a
+ * postura é fail-closed de novo.
  */
 export async function requireSudo(ctx, settings) {
     try {
@@ -85,7 +209,9 @@ export async function requireSudo(ctx, settings) {
             return true;
     }
     catch {
-        // FAIL-SAFE: erro ao resolver a setting → deixa passar.
+        // 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`.
         return true;
     }
     // Fora da graça: redireciona para confirmação.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@adonis-agora/authkit-server",
-  "version": "0.45.0",
+  "version": "0.46.0",
   "description": "AdonisJS OIDC/OAuth2 provider (Identity Provider) toolkit: ejectable auth server with sessions, rate-limiting, MFA/TOTP, audit log, federated logout and OpenTelemetry metrics.",
   "license": "MIT",
   "author": "dudousxd",
@@ -100,6 +100,7 @@
     }
   },
   "dependencies": {
+    "@simplewebauthn/browser": "^13.3.0",
     "@simplewebauthn/server": "^13.3.1",
     "jose": "^5.9.0",
     "koa": "^3.2.1",
@@ -130,6 +131,7 @@
     "@types/qrcode": "^1.5.5",
     "better-sqlite3": "^11.0.0",
     "edge.js": "6.5.1",
+    "esbuild": "0.25.12",
     "ioredis": "5.4.2",
     "ioredis-mock": "^8.9.0",
     "luxon": "3.7.2",
@@ -149,8 +151,10 @@
     "@adonis-agora/authkit-react": "0.16.0"
   },
   "scripts": {
-    "build": "node scripts/build_host_css.mjs && node scripts/build_ui.mjs && tsc && node -e \"require('node:fs').cpSync('stubs','build/stubs',{recursive:true,filter:(s)=>!s.endsWith('.ts')})\" && node -e \"const fs=require('node:fs');if(fs.existsSync('assets'))fs.cpSync('assets','build/assets',{recursive:true})\" && node -e \"require('node:fs').cpSync('src/host/views','build/host/views',{recursive:true})\" && node -e \"const fs=require('node:fs');fs.mkdirSync('build/host/ui',{recursive:true});fs.readdirSync('src/host/ui').filter(f=>f.endsWith('.html')).forEach(f=>fs.copyFileSync('src/host/ui/'+f,'build/host/ui/'+f))\" && node -e \"require('node:fs').copyFileSync('commands/commands.json','build/commands/commands.json')\" && node -e \"const fs=require('node:fs');fs.mkdirSync('build/password',{recursive:true});fs.copyFileSync('src/password/common_passwords.txt','build/password/common_passwords.txt')\"",
+    "build": "node scripts/build_host_css.mjs && node scripts/build_webauthn.mjs && node scripts/build_ui.mjs && node -e \"const fs=require('node:fs');for(const d of ['build/stubs','build/host/views'])fs.rmSync(d,{recursive:true,force:true})\" && tsc && node -e \"require('node:fs').cpSync('src/host/assets','build/src/host/assets',{recursive:true})\" && node -e \"require('node:fs').cpSync('stubs','build/stubs',{recursive:true,filter:(s)=>!s.endsWith('.ts')})\" && node -e \"const fs=require('node:fs');if(fs.existsSync('assets'))fs.cpSync('assets','build/assets',{recursive:true})\" && node -e \"require('node:fs').cpSync('src/host/views','build/host/views',{recursive:true})\" && node -e \"const fs=require('node:fs');fs.mkdirSync('build/host/ui',{recursive:true});fs.readdirSync('src/host/ui').filter(f=>f.endsWith('.html')).forEach(f=>fs.copyFileSync('src/host/ui/'+f,'build/host/ui/'+f))\" && node -e \"require('node:fs').copyFileSync('commands/commands.json','build/commands/commands.json')\" && node -e \"const fs=require('node:fs');fs.mkdirSync('build/password',{recursive:true});fs.copyFileSync('src/password/common_passwords.txt','build/password/common_passwords.txt')\"",
     "build:ui": "node scripts/build_ui.mjs",
+    "build:webauthn": "node scripts/build_webauthn.mjs",
+    "check:webauthn-bundle": "node scripts/check_webauthn_bundle.mjs",
     "typecheck": "tsc --noEmit && node scripts/typecheck_ui.mjs",
     "test": "node --import=@poppinss/ts-exec bin/test.ts",
     "build:host-css": "node scripts/build_host_css.mjs"

package/build/stubs/ui/edge/views/consent.edge

@@ -1,13 +0,0 @@
-{{{
-  exports({ to: app.makePath('resources/views/authkit/consent.edge') })
-}}}
-<!doctype html>
-<html lang="pt-br"><head><meta charset="utf-8"><title>Autorizar</title>
-<script src="https://cdn.tailwindcss.com"></script></head>
-<body class="min-h-screen flex items-center justify-center bg-gray-50">
-  <form method="POST" action="/auth/interaction/{{ uid }}/consent" class="w-full max-w-sm bg-white p-6 rounded-lg shadow">
-    <h1 class="text-lg font-semibold mb-2">Autorizar acesso</h1>
-    <p class="text-sm text-gray-600 mb-4">O app <strong>{{ params.client_id }}</strong> quer acessar sua conta.</p>
-    <button class="w-full bg-black text-white rounded py-2">Autorizar</button>
-  </form>
-</body></html>

package/build/stubs/ui/edge/views/login.edge

@@ -1,19 +0,0 @@
-{{{
-  exports({ to: app.makePath('resources/views/authkit/login.edge') })
-}}}
-<!doctype html>
-<html lang="pt-br"><head><meta charset="utf-8"><title>Entrar</title>
-<script src="https://cdn.tailwindcss.com"></script></head>
-<body class="min-h-screen flex items-center justify-center bg-gray-50">
-  <form method="POST" action="/auth/interaction/{{ uid }}/login" class="w-full max-w-sm bg-white p-6 rounded-lg shadow">
-    <h1 class="text-lg font-semibold mb-4">Entrar</h1>
-    @if(error)
-      <p class="text-red-600 text-sm mb-3">{{ error }}</p>
-    @end
-    <label class="block text-sm mb-1">E-mail</label>
-    <input name="email" type="email" required class="w-full border rounded px-3 py-2 mb-3" />
-    <label class="block text-sm mb-1">Senha</label>
-    <input name="password" type="password" required class="w-full border rounded px-3 py-2 mb-4" />
-    <button class="w-full bg-black text-white rounded py-2">Entrar</button>
-  </form>
-</body></html>

package/stubs/ui/edge/views/consent.edge

@@ -1,13 +0,0 @@
-{{{
-  exports({ to: app.makePath('resources/views/authkit/consent.edge') })
-}}}
-<!doctype html>
-<html lang="pt-br"><head><meta charset="utf-8"><title>Autorizar</title>
-<script src="https://cdn.tailwindcss.com"></script></head>
-<body class="min-h-screen flex items-center justify-center bg-gray-50">
-  <form method="POST" action="/auth/interaction/{{ uid }}/consent" class="w-full max-w-sm bg-white p-6 rounded-lg shadow">
-    <h1 class="text-lg font-semibold mb-2">Autorizar acesso</h1>
-    <p class="text-sm text-gray-600 mb-4">O app <strong>{{ params.client_id }}</strong> quer acessar sua conta.</p>
-    <button class="w-full bg-black text-white rounded py-2">Autorizar</button>
-  </form>
-</body></html>

package/stubs/ui/edge/views/login.edge

@@ -1,19 +0,0 @@
-{{{
-  exports({ to: app.makePath('resources/views/authkit/login.edge') })
-}}}
-<!doctype html>
-<html lang="pt-br"><head><meta charset="utf-8"><title>Entrar</title>
-<script src="https://cdn.tailwindcss.com"></script></head>
-<body class="min-h-screen flex items-center justify-center bg-gray-50">
-  <form method="POST" action="/auth/interaction/{{ uid }}/login" class="w-full max-w-sm bg-white p-6 rounded-lg shadow">
-    <h1 class="text-lg font-semibold mb-4">Entrar</h1>
-    @if(error)
-      <p class="text-red-600 text-sm mb-3">{{ error }}</p>
-    @end
-    <label class="block text-sm mb-1">E-mail</label>
-    <input name="email" type="email" required class="w-full border rounded px-3 py-2 mb-3" />
-    <label class="block text-sm mb-1">Senha</label>
-    <input name="password" type="password" required class="w-full border rounded px-3 py-2 mb-4" />
-    <button class="w-full bg-black text-white rounded py-2">Entrar</button>
-  </form>
-</body></html>