← Назад к заметкам

Заметки

Как хранить OAuth-токены приложения

Как хранить OAuth-токены приложения: Refresh token, база, безопасность, переустановка.

Как хранить OAuth-токены приложения. Основной фокус: Refresh token, база, безопасность, переустановка.

Задача

Разобрать поведение локального или OAuth-приложения, placement, слайдер или установку.

Задача — как хранить OAuth-токены приложения. Refresh token, база, безопасность, переустановка.

Главное — не искать один универсальный метод, а сначала определить сущность, права и слой API, через который выполняется действие.

Как это устроено

Приложение работает внутри контекста портала: место встройки передаёт параметры, OAuth ограничивает права scope, а iframe накладывает ограничения браузера и безопасности.

OAuth-приложение живёт на паре access token и refresh token. Если токены не сохранены или приложение переустановили, старые запросы будут выглядеть как будто приложение не установлено.

Если сценарий проверяется под администратором, отдельно повторите его под обычным пользователем. Для прав, CRM, задач, Диска и приложений это часто даёт другой результат.

Рабочий подход

Проверяйте установку приложения, handler URL, права, scopes и фактический результат BX24.placement.info. Для карточек CRM не просите пользователя вводить ID вручную — берите его из контекста размещения.

Сделайте минимальный тест на одной сущности, сохраните входные данные и ответ метода, а затем расширяйте решение на массовый сценарий.

На коробке удобнее добавлять временное логирование рядом с местом выполнения кода, а в облаке — сохранять входящие и исходящие REST-запросы в свой журнал интеграции.

Частые ошибки

Если после placement.bind открывается install.php, часто проблема не в самом placement, а в URL обработчика, незавершённой установке или старой записи размещения.

  • Проверять сценарий только под администратором и не видеть проблему прав обычного пользователя.
  • Регистрировать placement до завершения установки и ждать, что он сразу появится у всех пользователей.
  • Не логировать фактический запрос и ответ, из-за чего ошибка выглядит случайной.

Минимальный пример

Пример показывает только форму вызова. ID, права, обработчики и поля нужно заменить под свой портал.

// access_token используйте для текущих запросов.
// refresh_token храните на сервере и обновляйте пару токенов до истечения доступа.