Как получить значение user_api_keys через API

Разработка
1

Привет! Я хотел бы задать вопрос по поводу user_api_keys. В настоящее время я работаю над интеграцией нашего приложения для использования user_api_keys в Discourse для авторизации. Мой вопрос: существует ли способ получить user_api_keys через API?

В данный момент после входа через /session.json и проверки профиля текущего пользователя через /users/:username.json мы можем увидеть, есть ли у пользователя user_api_keys, но при этом не возвращаются их фактические значения:

"user_api_keys": [
  {
    "id": 0,
    "application_name": "",
    "scopes": [""],
    "created_at": "",
    "last_used_at": ""
  }
]

Причина, по которой я хочу получить значение user_api_keys, заключается в том, чтобы избежать повторного запроса у пользователя подтверждения авторизации после того, как он уже одобрил её при первом входе, нажав кнопку.

2

Нет, они отображаются один раз, после чего сохраняется только хеш.

Ключ API пользователя должен храниться в вашем приложении, предпочтительно на устройстве конечного пользователя. Вся суть ключа API пользователя заключается в том, что он служит «доказательством» авторизации, и ответственность за его хранение лежит на пользователе.

3

Я не думаю, что возможно получить значение ключа API через сам API. Discourse не сохраняет незашифрованные ключи API в базе данных. Даже если бы вы могли получить зашифрованное значение, не было бы способа расшифровать его в вашем приложении.

Можете ли вы немного подробнее объяснить ваш случай использования? Если ключ API пользователя уже сгенерирован для пользователя, мне неясно, почему им потребуется одобрять авторизацию во второй раз.

Редактирование: возможно использовать Административный ключ API для генерации ключа API для пользователя. Некоторые подробности об этом здесь: Generate User Api Key Without User Approval - #2 by simon

Повторно перечитав свой пост, я вижу, что не объяснил, как была установлена переменная $json для запроса. Самый простой способ понять, как структурировать данные, — сделать запрос на генерацию одного ключа API пользователя с нужными вам областями доступа через интерфейс Discourse, а затем посмотреть значение полезной нагрузки запроса, отправляемой при запросе к /admin/api/keys:

20240922_22h55m56s_grim
20240922_22h55m56s_grim1224×509 83 KB

4

Привет @RGJ, спасибо за твой ответ.

5

Привет, @simon, спасибо за ответ. Позвольте подробнее описать нашу ситуацию.

Мы разрабатываем мобильное приложение, которое опирается на серверную логику конечных точек Discourse. Когда пользователь входит в приложение, данные аутентификации отправляются в API Discourse через session.json, который возвращает cookie. Этот cookie затем используется для перенаправления веб-вью на /user-api-key/new, где пользователю предлагается подтвердить авторизацию. После подтверждения полезная нагрузка расшифровывается в API-ключи.

В таком случае мы можем использовать API-ключи как глобальный токен внутри мобильного приложения для доступа к другим конечным точкам Discourse. Однако при выходе пользователя токен должен быть удалён из глобального состояния, чтобы он больше не мог обращаться к таким конечным точкам, как создание новой темы.

Мой вопрос исходит из этой темы: как проверить, есть ли у пользователя уже user_api_keys и активны ли они? Если ключи существуют и активны, пользователь должен иметь возможность использовать их после входа. Если нет, пользователю потребуется создать новые user_api_keys, что потребует подтверждения через веб-вью.

Это основная проблема, с которой я столкнулся.

Ещё одно решение, которое я рассмотрел, основано на сообщении из Как получить значение ключа API пользователя через API: хранить API-ключи в базе данных нашего мобильного приложения.

Я также обратился к посту Генерация ключа API пользователя без подтверждения пользователем - #2 от simon, который изначально рассматривал для реализации ключей API. Однако проблема остаётся прежней: при проверке /admin/api/keys мы не можем получить значение уже сохранённых в базе данных ключей API или получить ключи API для конкретного пользователя. Я полагаю, что для такой реализации нам необходимо хранить API-ключи в нашей собственной базе данных.

6

Возможно, вы могли бы сгенерировать токен сессии, отдельный от ключа API. Используйте этот токен для обозначения статуса входа пользователя. Таким образом, вам не придется удалять ключ API при выходе пользователя из системы.

7

Спасибо за ваш вклад в решение этой проблемы. Я согласен, что токен лучше хранить в двух местах: во-первых, в глобальном состоянии для проверки статуса входа пользователя, и во-вторых, в базе данных для хранения user_api_keys.

8

Почему бы не использовать Discourse Connect? Это правильный способ аутентификации.

9

Привет, спасибо за ваше предложение. Мы не используем Discourse Connect здесь, потому что не подключаем Discourse к другим веб-сайтам или ресурсам. Вся функциональность входа будет обрабатываться напрямую через Discourse, а приложение будет взаимодействовать только с Discourse.

11

Ваше приложение — это другое место. Я почти уверен, что вы хотите настроить своё приложение как клиент Discourse Connect, чтобы пользователи могли входить в ваше приложение, авторизовавшись в Discourse. Тогда ваше приложение сможет взаимодействовать с Discourse, я так думаю. Или, возможно, я не понимаю, как работают приложения.