Saiba em qual backend está se autenticando

Permissões exatas e automação opcional

Um site como https://client.example pode usar https://api.client.example. Uma permissão HTTP salva vincula conta ativa, origem do site, URL assinada exata com consulta e método HTTP. Não autoriza outros destinos, métodos, sites ou contas. Permissões antigas por origem exigem novo consentimento; negativas continuam válidas.

Autenticação padrão do backend começa desativada por conta. Ativada em Permissões, permite NIP-98 automático para sites conectados na mesma origem HTTPS exata ou num par site/backend marcado nip98 no registro e suas regras. Inclui caminhos e métodos válidos dessas origens. Entradas apenas informativas, não verificadas ou com curingas não bastam. Negativas explícitas prevalecem. Relays têm permissões separadas.

Revisar e gerenciar a autenticação

A solicitação mostra site, destino e método. Aprovar e Negar afetam apenas essa solicitação. As setas salvam decisões para conta, site, URL e método. O ícone de código abre o evento completo. Aprovação em lote de assinaturas comuns não concede permissão permanente de autenticação.

Abra Permissões → Autenticação do backend. Quando a política está ativa, um aviso explica o alcance e oferece links para as regras e o registro. Aprovações automáticas não criam linhas: uma tabela vazia não significa política desativada. A tabela mostra decisões explícitas da conta ativa.

Revogue uma entrada ou desative a política em Permissões. Desativá-la mantém permissões explícitas. A revogação afeta assinaturas futuras, não provas enviadas nem sessões já criadas. HTTP não oferece permissão para todos os sites.

O que a extensão verifica

A origem vem da identidade do documento fornecida pelo navegador. A página não pode escolher outra origem em um campo RPC. A autenticação exige um quadro principal verificado; iframes, inclusive da mesma origem, e origens opacas ou inconsistentes são recusados. HTTPS é obrigatório, salvo exceções explícitas de desenvolvimento em loopback.

São rejeitados tags obrigatórias ambíguas, URLs inválidas, conteúdo inesperado e timestamps vencidos. As tags opcionais origin e client-origin devem coincidir com a origem real. Acesso ao site, permissões e sessão da conta são verificados novamente após aprovação ou desbloqueio. Um assinante NIP-46 deve devolver uma assinatura da conta esperada sobre o evento aprovado inteiro, inclusive a ordem das tags.

Proteção da carteira integrada

Criar ou recuperar uma carteira e gerenciar endereços Lightning usa o protocolo v2 do LNbits-proxy. O assinante genérico de sites recusa tokens para essas rotas sensíveis.

A prova vincula URL, método e hash dos bytes exatos do corpo. O desafio do backend dura 60 segundos e só pode ser consumido uma vez. Um token de transação separado vai em seu próprio cabeçalho; apenas seu hash é assinado. O servidor verifica a assinatura e os vínculos antes de consumir o desafio atomicamente. Pedidos do navegador também exigem uma origem HTTPS permitida e um client-origin assinado correspondente. Rotas antigas retornam 426; não há retorno ao protocolo anterior.

Limites

NIP-98 depende de o backend validar URL e método. A extensão não pode obrigar outros servidores a implementar essa validação. Quem possui uma prova válida e os tokens exigidos pode encaminhá-los ao destino correto antes do primeiro uso.

CORS restringe navegadores, não chamadas entre servidores. Uma tag de origem não comprova criptograficamente o navegador. Código malicioso dentro de um site principal autorizado compartilha sua autoridade. Esses controles limitam o consentimento, mas não eliminam todo phishing ou encaminhamento de autenticação.

Veja o contrato v2 e os testes de autenticação.