Немедленное отключение доступа к обновлениям профиля и отмена глобальной сессии (3 правила)

Поток регистрации в Healthtech может пройти свою капчу и все равно оставить опасный пробел: учетная запись запрещена в базе данных профиля, в то время как уже выпущенная сессия продолжает работать. Это инцидент контроля доступа, ожидающий, когда часы закончатся. Краткий ответ: смоделируйте запрет как осуществимый переход профиля к состоянию, а затем отмените каждую сессию как отдельное, явное действие жизненного цикла. Сохраняйте учетные данные краткосрочного доступа и его возможности обновления под различными контролем риска и делайте операции «это устройство» и «все устройства». Урок инцидента: флаг профиля не является выключателем Операционное ограничение - немедленное отключение. Когда обзор злоупотреблений отмечает пользователя как запрещенный, система должна прекратить новую работу и аннулировать существующий доступ, не полагаясь на кнопку выхода из браузера. Меня вызвали на страницы за пропущенную работу и дублирование поставок; здесь применим тот же урок: изменение состояния полезно только в том случае, если его соблюдает каждый потребитель. Инвариант прост: каждое действие аутентификации является проверяемым, проверяемым, восстанавливаемым переходом состояния. Защита регистрации (включая верификацию captcha) является одним из переходов. Создание сеанса, проверка, обновление и отзыв еще четыре. Обращение к ним как к одному гигантскому «запросу на аутентификацию» делает невозможным ответ на вопрос аудита, такой как «какой сеанс был активным после запрета?» Сначала напишите запрет с аудиторской записью, которая связывает пользователя с оператором, причиной и запросом ID. Затем выдайте глобальную команду отзыва. Заказ имеет значение, потому что отзыв без длительного состояния профиля может быть отменен автоматическим обновлением; обновление профиля без отзыва оставляет старые учетные данные на предъявителя живыми до истечения срока действия. Звучит очевидно. Его часто упускают. Как обновления профиля государства должны привести к отзыву глобальной сессии? Используйте два явных вызова и одну границу транзакции в вашем собственном сервисе. Изменение состояния профиля. Отменяет сеансы на каждом устройстве. Они являются отдельными глаголами, потому что они имеют отдельную семантику аудита и поведение повтора. Абонент должен прикрепить ключ идемпотентности к пути записи, сохранить решение до совершения сетевого вызова и записать оба ответа. Повторная попытка после тайм-аута должна воспроизводить одно и то же решение, а не создавать второе событие запрета или молча переключаться с одного пользователя на другого. На HTTP 429, почет и отступление; плотный цикл во время всплеска злоупотребления может стать его собственным отказом в обслуживании. На практике я сохраняю строку аудита, выбранный идентификатор пользователя, версию политики и ключи идемпотентности в одной прочной записи, а затем позволяю работнику воспроизводить точную пару вызовов, пока не будут известны оба результата. Этот работник также выдает метрику для «обновленного профиля, сессии все еще активны», потому что зеленый ответ от первого звонка не является доказательством того, что отключение завершено; вспомогательный персонал нуждается в ограниченной, наблюдаемой передаче между этими двумя государствами. Вот компактный Go-обработчик. Окружающее приложение владеет авторизацией, хранилищем аудита и политикой, которая решает, запрещен ли профиль. Звонки API намеренно ограничены двумя операциями, имеющими отношение к отключению. Пример предполагает, что доверенный бэкэнд уже аутентифицировал рецензента. Он не помещает ключ в источник, и он всплывает в корпус non-2xx, чтобы оператор мог соотнести сбой с аудиторской записью. Ваш пробег может варьироваться на окнах повторного использования; выберите тот, который короче, чем позволяет ваша политика инцидента, и предупредите, когда вызов на отзыв остается на рассмотрении. Короткие учетные данные, длинные последствия Токены доступа должны быть недолговечными, потому что они часто представлены и их трудно вспомнить после копирования. Возможность обновления заслуживает другого контроля: привязать его к записи сеанса, повернуть ее при использовании и отозвать эту запись, когда пользователь запрещен. Проверщик токенов должен проверять как подпись, так и текущее состояние сессии; только подлинность подписи не является доказательством того, что доступ все еще разрешен. Проверка и обновление являются независимыми действиями жизненного цикла. Успешное обновление не должно воскресить отмененную сессию и провал