ТЛ;ДР Проверка аутентификации, использующая ===, где обе стороны могут быть неопределенными, называется отказооткрытой — отсутствующая конфигурация превращает ее из заблокированной в открытую. Единственным секретом, отсутствовавшим в .env.example, был внутренний токен аутентификации. Не установлено при развертывании, не определено === не определено...
ТЛ;ДР
Проверка аутентификации, использующая ===, где обе стороны могут быть неопределенными, называется отказооткрытой — отсутствующая конфигурация превращает ее из заблокированной в открытую.
Единственным секретом, отсутствовавшим в .env.example, был внутренний токен аутентификации. Не установлено при развертывании, undefined === undef пропускает каждый анонимный запрос.
По умолчанию запрещено: проверять типы, отклонять пустые данные, сравнивать за постоянное время и писать тест, который не отправляет учетные данные с неустановленной переменной env.
Агент кодирования передал мне промежуточное программное обеспечение для аутентификации. Оно прошло проверку. Я почти отправил его.
функция Protect(req, res, next) {
if (req.headers['x-internal-token'] ===process.env.INTERNAL_API_TOKEN) return next();
вернуть requireAuth()(req, res, next);
}
Четыре строчки, и все читается нормально. Внутренняя служба вызывает общий токен и пропускает процесс входа в систему; все остальные попадают в настоящую аутентификацию. Затем я проверил, что происходит, когда токен не установлен.
Что на самом деле сделала проверка
INTERNAL_API_TOKEN — единственный секрет, отсутствующий в .env.example. Все остальные ключи были на месте — Страйп, Клерк, Паддл, — но только не этот. Таким образом, при развертывании, где никто не думал его устанавливать, процесс.env.INTERNAL_API_TOKEN не определен.
Теперь приходит обычный запрос браузера. Он не отправляет x-inte