Controlla a quale backend ti stai autenticando

Autorizzazioni precise e automazione facoltativa

Un sito come https://client.example può usare https://api.client.example. Un’autorizzazione HTTP salvata lega account attivo, origine del sito, URL firmato esatto con query e metodo HTTP. Non copre altre destinazioni, metodi, siti o account. Le vecchie autorizzazioni per origine richiedono nuovo consenso; i rifiuti restano validi.

Autenticazione backend predefinita è inizialmente disattivata per account. Attivandola in Permessi, i siti collegati possono usare NIP-98 automaticamente per la stessa origine HTTPS esatta o una coppia sito/backend marcata nip98 nel registro e nelle regole. Sono inclusi percorsi e metodi validi di tali origini. Una voce informativa, non verificata o con caratteri jolly non basta. I rifiuti espliciti prevalgono. I relay hanno permessi separati.

Esaminare e gestire l’autenticazione

La richiesta indica sito, destinazione e metodo. Approva e Nega riguardano solo questa richiesta. Le frecce memorizzano la decisione per account, sito, URL e metodo. L’icona del codice apre l’evento completo. L’approvazione collettiva di firme ordinarie non concede un permesso permanente di autenticazione.

Apri Permessi → Autenticazione del backend. Se la politica è attiva, un avviso ne spiega l’ambito e collega regole e registro. Le approvazioni automatiche non creano righe: una tabella vuota non significa che la politica sia disattivata. La tabella mostra le decisioni esplicite dell’account attivo.

Revoca una voce oppure disattiva la politica in Permessi. Disattivarla conserva i permessi espliciti. La revoca riguarda firme future, non prove inviate o sessioni già create. HTTP non offre autorizzazioni per tutti i siti.

Verifiche dell’estensione

L’origine deriva dall’identità del documento fornita dal browser, non da un valore scelto dalla pagina. Serve un frame principale verificato. Iframe, anche della stessa origine, e origini opache o incoerenti vengono rifiutati. HTTPS è obbligatorio salvo eccezioni esplicite di sviluppo in loopback.

Tag obbligatori ambigui, URL invalidi, contenuti inattesi e timestamp scaduti vengono rifiutati. I tag facoltativi origin e client-origin devono corrispondere all’origine reale. Accesso, permessi e sessione dell’account vengono ricontrollati dopo l’attesa di approvazione o sblocco. Una risposta NIP-46 deve avere la firma dell’account previsto e coincidere con l’intero evento approvato, ordine dei tag compreso.

Operazioni del wallet integrato

Creazione o recupero del wallet e gestione degli indirizzi Lightning usano LNbits-proxy v2. Il firmatario generico dei siti rifiuta token per queste rotte sensibili.

La prova vincola URL, metodo e hash dei byte esatti del corpo. Una challenge del backend dura 60 secondi e si usa una sola volta. Un token di transazione separato viaggia in un proprio header; viene firmato solo il suo hash. Il server controlla firma e vincoli prima di consumare atomicamente la challenge. Le chiamate del browser richiedono anche un’origine HTTPS consentita e un client-origin firmato corrispondente. Le vecchie rotte rispondono 426 e il client non torna al vecchio protocollo.

Limiti

NIP-98 richiede che il backend verifichi URL e metodo. L’estensione non può imporre questa verifica a tutti i server. Chi possiede una prova valida e i token necessari può inoltrarli alla destinazione prevista prima del primo utilizzo.

CORS limita i browser, non le richieste tra server. Un tag di origine non è un’attestazione crittografica del browser. Codice malevolo nel sito principale autorizzato ne condivide i poteri. Questi controlli limitano il consenso, ma non eliminano ogni phishing o inoltro di autenticazione.

Consulta il contratto v2 e i test.