Токен GitHub вырос с 40 до 520 символов: где сломается интеграция
Если интеграция перестала принимать установочный токен GitHub App, вероятная причина — зависимость от прежней длины или алфавита. Новое значение сохраняет префикс ghs_, но использует переменный формат ghs_APPID_JWT длиной около 520 символов вместо прежних 40; журнал изменений GitHub рекомендует вмещать не менее 520 символов и не разбирать внутреннее содержимое токена.
Проверить нужно весь маршрут секрета: получение, проверку формы, временное хранение, очередь, базу данных, прокси, заголовок авторизации и журналирование. Токен следует обрабатывать как непрозрачную строку: его внутренняя структура не должна становиться источником идентификаторов, срока действия или решений о доступе.
Почему прежняя проверка отклоняет новое значение
Устаревший код часто ожидает префикс и ещё ровно 36 буквенно-цифровых знаков. Такое предположение встречается в сравнении длины с 40, выражении ghs_[A-Za-z0-9]{36}, фиксированном буфере, ограничении модели запроса или столбце VARCHAR(40).
Новый вариант длиннее и может содержать точки, дефисы и дополнительные знаки подчёркивания. Поэтому ошибка способна возникнуть до основной таблицы: при разборе ответа, преобразовании объекта, постановке задания в очередь или передаче значения между службами.
Не заменяйте старое жёсткое условие другим разбором внутренней структуры. Даже если части строки внешне напоминают составной токен, приложение не должно извлекать из них сведения и считать эти сведения устойчивым контрактом.
Где искать ограничение длины
Проверяйте путь от ответа службы до исходящего запроса, а не только основное поле базы данных. Расширенный столбец не поможет, если значение уже обрезала форма, библиотечная обёртка или промежуточная очередь.
- Модели данных. Найдите максимальную длину 40, фиксированные массивы, автоматическое обрезание и проверку только букв и цифр.
- База данных. Проверьте основной столбец, временные таблицы, параметры процедур, ограничения объектной модели, кэш и копии поля в очередях. Переменный символьный тип с запасом безопаснее точного предела 520, поскольку формат объявлен переменным.
- Хранилище секретов. Проверьте форму записи, шаблоны конфигурации и доставку значения. Ни один слой не должен добавлять кавычки, перенос строки или молча сокращать содержимое.
- Передача запроса. Проследите формирование заголовка Authorization, а также ограничения шлюза, обратного прокси, служебной сетки и собственных обработчиков. Общего допустимого размера заголовка недостаточно, если локальная переменная короче.
- Шифрование. Отдельно измерьте результат шифрования и текстового кодирования. Размер исходной строки и требуемая вместимость столбца с шифротекстом не совпадают.
Для поиска скрытых ограничений полезна синтетическая строка длиной больше 520 символов с точками, дефисами и знаками подчёркивания. Она не является действующим секретом, но позволяет проверить сохранение, передачу и маскирование без риска раскрыть рабочие учётные данные.
Как обновить регулярное выражение
Если системе достаточно проверить наличие значения, регулярное выражение для внутренней структуры не нужно. Когда на входной границе требуется отсеять явно неверный тип, проверка должна распознавать оба представления, но не подменять подтверждение подлинности.
Инструкция по совместимости двух форматов приводит выражение ghs_[A-Za-z0-9.\-_]{36,}. Оно допускает переменную длину и новые разделители, однако подтверждать полномочия по результату совпадения нельзя: действительность значения определяется ответом платформы и разрешениями установки.
Не требуйте наличия ровно двух точек. Новое представление их содержит, но прежнее не содержит и может оставаться действительным до истечения своего срока. По той же причине внутренние части строки нельзя использовать для маршрутизации, вычисления срока действия или локального решения об авторизации.
Как провести сквозную проверку без утечки
Временный заголовок X-GitHub-Stateless-S2S-Token позволяет запросить нужное представление для отдельного выпуска: значение enabled выбирает новое, disabled — прежнее. Это средство предназначено для переходной проверки, поэтому его не следует превращать в постоянную зависимость рабочего кода.
- В тестовой среде получите новое представление и проведите его тем же маршрутом, который используется в рабочей системе.
- Выполните разрешённый запрос и сохраните только итоговый код ответа, длину значения и факт ожидаемого префикса.
- Повторите маршрут с прежним представлением, чтобы обнаружить код, ошибочно требующий точки или составную структуру.
- Проверьте отказ хранилища, повторную доставку очереди и ошибку прокси. Секрет не должен появляться в исключении, трассировке или снимке задания.
Положительный тест должен доказывать не только приём значения, но и его неизменность между слоями. Для этого можно сравнивать длину и контрольную сумму синтетической строки, не записывая саму строку в отчёт или журнал.
Как закрыть утечки и выпускать токен
Маскирование, рассчитанное на префикс и ровно 36 последующих знаков, способно скрыть лишь начало длинного значения. Удаляйте весь заголовок авторизации по имени поля до сериализации события, а из структурированного ответа исключайте поле с токеном целиком.
Проверьте журналы клиента, прокси, очередей, ошибок проверки и отладочной трассировки. Безопасный тест подтверждает отсутствие синтетического значения, а также его начального и конечного фрагментов: одной визуальной замены середины строки недостаточно.
Способ получения секрета не меняется: официальная инструкция по выпуску токена описывает запрос к ресурсу установки с подписанным удостоверением приложения. Библиотека Octokit может взять выпуск и обновление значения на себя.
Интеграция совместима, если оба представления проходят полный маршрут без отклонения, обрезания и раскрытия. Контрольная проверка должна охватывать модель входа, базу данных, очередь, хранилище секретов, прокси, заголовок авторизации и все точки журналирования.
Читайте также:
Подпишитесь на рассылку
Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.