Доступ на сайт по токену: проверка права пользователя
Абонемент появился в сети, но сайт ещё не знает, кто открыл страницу. Значение address, переданное браузером, является только заявлением. Любой посетитель может написать адрес другого владельца. Поэтому проверка balanceOf для произвольного адреса не устанавливает личность текущей сессии и сама по себе не разрешает выдачу закрытого материала.
Введём отдельный серверный сценарий: читатель подтверждает контроль над адресом, сервер связывает его со своей сессией и проверяет владение определённым токеном. Это расширение веб-приложения. Оно не меняет LibraryPass, не добавляет ему редакционных ролей и не превращает публичные ресурсы ProfessorWeb в секретные файлы.
Вход и полномочие
У процедуры два вопроса. Первый: какой адрес подтверждён для данной сессии? Второй: удовлетворяет ли его текущее состояние правилу доступа? Подпись входа относится к первому. Чтение token balance или ownerOf относится ко второму. Изменение одного ответа не обязательно меняет другой автоматически.
Для сообщения входа существует Sign-In with Ethereum, ERC-4361. Оно описывает структурированные поля, включая домен, URI, chain ID, nonce и время выпуска. В уроке не реализуем криптографический verifier вручную. Полноценный обработчик должен разбирать и проверять сообщение по договору стандарта и отдельно обрабатывать контрактные аккаунты.
Ниже показана предметная последовательность, а не готовый сервер и не запущенные запросы. Она специально делает разные проверки отдельными шагами.
1. Сервер создаёт непредсказуемый одноразовый nonce для попытки входа.
2. Клиент подписывает согласованное сообщение для данного домена и сети.
3. Сервер проверяет сообщение, подпись, срок и привязку к своей попытке.
4. Nonce перестаёт быть доступным для повторного входа.
5. Сессия хранит подтверждённый адрес.
6. Сервер читает определённую коллекцию в определённой сети.
7. Правило разрешает услугу, если подтверждённый адрес имеет абонемент.Случайная строка nonce нужна для различения попыток и предотвращения повторного использования принятого сообщения. Идентификатор из URL страницы не заменяет непредсказуемость. Также отсутствие защиты от повторного применения нельзя компенсировать только надписью «подписано кошельком»: та же подпись останется той же подписью.
Область сообщения
Домен и URI ограничивают смысл входа выбранным сайтом. Сообщение для другого сервиса нельзя принимать как собственную авторизацию только потому, что из него восстановился тот же адрес. Сервер проверяет ожидаемые поля, а не собирает произвольный текст, который пользователь когда-то подписал.
Chain ID особенно важен для последующей проверки токена. LibraryPass в локальной сети и коллекция с похожим названием в иной сети — разные состояния. Сессия не должна тихо проверять другой экземпляр после переключения кошелька. Настройка услуги включает сеть и полный адрес контракта, а не только символ LPASS.
Срок сообщения и срок сессии тоже различаются. Подписанное намерение может быть приемлемо лишь короткое время, а созданная сессия жить по собственной политике. Длинная сессия требует решения, когда повторять проверку токенного права, иначе передача абонемента не приведёт к ожидаемой потере услуги.
Текущее владение и кэш
Пусть R вошёл, имея tokenId 1. Затем он передал его Q. Если правило сформулировано как текущее владение, поздний запрос R должен учитывать переход. Проверка только при первом входе реализует другое правило: право на весь срок ранее выданной сессии. Оба варианта технически возможны, но их нельзя объявлять взаимозаменяемыми.
Кэш чтения снижает нагрузку, однако создаёт промежуток задержки отзыва. Документируйте допустимое время устаревания и выбранный уровень подтверждения сети. Для бесплатной лабораторной страницы возможен простой договор; для иной услуги требуется отдельная оценка последствий временной ошибки.
Если RPC недоступен, сервер не знает нового результата. Доступ по старому кэшу и отказ до восстановления — разные политики отказа. Не представляем случай сбоя как доказанное отсутствие токена. Пользовательское сообщение должно отличать неизвестное состояние от известного неподходящего состояния.
Публичный файл остаётся публичным
Скрытие кнопки на статической странице не закрывает файл. Если URL ресурса доступен без серверной проверки, посетитель может открыть его напрямую или сохранить ранее. Аналогично токен не шифрует JSON и изображения, опубликованные в IPFS. Он является учётным фактом, а не механизмом секретности произвольных байтов.
Для действительно ограниченной услуги защищают маршрут получения на сервере и проверяют сессию там. Даже тогда полученные пользователем данные могут быть скопированы. Токенное условие отвечает на вопрос первоначального разрешения, но не предотвращает все дальнейшие способы распространения прочитанного материала.
В нашем образовательном сайте большая часть материалов предназначена для публичного поиска и чтения. Токенную модель можно использовать для демонстрационного лабораторного кабинета или дополнительной услуги, не выдавая её за необходимое условие доступа ко всей библиотеке. Такое разделение сохраняет смысл прежних открытых URL.
Владение не равно операторскому разрешению
Если S получил approve на токен R, он может быть уполномочен передать его, но не обязательно является допустимым читателем по нашему правилу. Правило «владелец имеет услугу» проверяет ownerOf либо balanceOf подтверждённого адреса. Использование isApprovedForAll без отдельного решения расширило бы круг получателей.
Контрактный кошелёк может владеть абонементом, однако его подпись не обязана проверяться обычным восстановлением EOA. Для соответствующего маршрута используется поддерживаемая проверка контрактной подписи и её текущая политика. Нельзя автоматически отвергать всех владельцев-контрактов или, наоборот, принять любую строку от имени контракта.
В самостоятельном разборе возьмите R как подтверждённого владельца, S как оператора и Q как нового владельца после transfer. Запишите, кто получает услугу до перехода и после него, какой nonce потреблён и когда истекает кэш. Это уже точное правило приложения, которое можно впоследствии проверять, а не неопределённое обещание «доступа через NFT».
Переданный адрес и подтверждённый адрес
Рассмотрим запрос браузера с address=R, когда подписанная серверная сессия принадлежит X. Правило использует X из проверенной сессии. Значение R в параметрах может быть полезно для публичной страницы просмотра, но оно не заменяет субъект авторизации. Иначе пользователь без абонемента прочитает услугу от имени любого подходящего держателя.
То же относится к выбранному tokenId. Если пользователь запрашивает номер другого владельца, ownerOf подтверждает принадлежность этого номера, но сервер должен сравнить результат со своим подтверждённым адресом. Сам факт существования токена не является достаточным условием. Сохраните эту проверку как предметное равенство в описании маршрута, чтобы будущая реализация не ограничилась только успешным RPC-ответом.
Для самостоятельного уточнения: eip-4361, eip-1271, ERC721.sol (5.4.0).
Оглавление курса. Листинги, расчёты и наблюдения здесь разобраны как ожидаемое поведение; компиляция, учебные программы и проверки при написании не запускались.