Проверяйте, на каком сервере вы проходите аутентификацию

Точные разрешения и необязательная автоматизация

Сайт https://client.example может использовать https://api.client.example. Сохранённое HTTP-разрешение связывает активный аккаунт, origin сайта, точный подписанный URL с параметрами запроса и HTTP-метод. Оно не действует для других адресов, методов, сайтов или аккаунтов. Старые разрешения на весь origin требуют нового согласия; запреты сохраняются.

Default backend auth изначально выключена для каждого аккаунта. При включении в Permissions подключённые сайты могут автоматически использовать NIP-98 для того же точного HTTPS-origin или пары сайт/backend с отметкой nip98 в реестре и правилах. Политика охватывает допустимые пути и методы этих origins. Информационной, непроверенной записи или маски домена недостаточно. Явные запреты имеют приоритет. Разрешения реле остаются отдельными.

Проверка и управление аутентификацией

Запрос показывает сайт, адрес и метод. Approve и Deny действуют только на текущий запрос. Меню со стрелками сохраняют решение для аккаунта, сайта, URL и метода. Значок кода открывает исходное событие. Групповое одобрение обычных подписей не даёт постоянного разрешения на аутентификацию.

Откройте Permissions → Backend authentication. При включённой политике уведомление объясняет её область действия и содержит ссылку на правила и реестр. Автоматические одобрения не создают отдельных строк: пустая таблица не означает, что политика выключена. В таблице показаны явные решения для активного аккаунта.

Отзовите запись здесь или отключите политику в Permissions. Отключение сохраняет явные разрешения. Отзыв влияет на будущие подписи, а не на уже отправленные доказательства и созданные сеансы. HTTP не поддерживает разрешение для всех сайтов.

Что проверяет расширение

Источник определяется по данным документа от браузера, а не по выбранному страницей параметру RPC. Требуется проверенный основной фрейм. Iframe, в том числе с тем же источником, а также непрозрачные или противоречивые источники отклоняются. Нужен HTTPS, кроме явно разрешённых случаев разработки через loopback.

Отклоняются неоднозначные обязательные теги, неверные URL, неожиданное содержимое и устаревшие метки времени. Необязательные теги origin и client-origin должны совпадать с реальным источником. После ожидания одобрения или разблокировки повторно проверяются доступ, разрешения и сессия аккаунта. Ответ NIP-46 должен содержать подпись ожидаемого аккаунта и точно соответствовать одобренному событию, включая порядок тегов.

Операции встроенного кошелька

Создание или восстановление кошелька и управление Lightning-адресами используют LNbits-proxy v2. Обычный механизм подписания для сайтов отклоняет токены этих чувствительных маршрутов.

Подтверждение связывает URL, метод и хеш точных байтов тела. Задание сервера действует 60 секунд и используется один раз. Отдельный токен транзакции передаётся в собственном заголовке; подписывается только его хеш. Сервер проверяет подпись и все связи до атомарного использования задания. Запросы браузера также требуют разрешённого HTTPS-источника и соответствующего подписанного client-origin. Старые маршруты возвращают 426; клиент не переключается на прежний протокол.

Ограничения

NIP-98 требует проверки URL и метода на сервере. Расширение не может заставить любой внешний сервер проверять их правильно. Обладатель действительного подтверждения и необходимых токенов может переслать их по исходному назначению до первого использования.

CORS ограничивает браузеры, но не запросы между серверами. Тег источника не является криптографическим свидетельством браузера. Вредоносный код внутри разрешённой основной страницы обладает её полномочиями. Эти проверки ограничивают согласие, но не исключают весь фишинг и пересылку подтверждений.

См. протокол v2 и тесты.