Onedrive OAuth 2.0 поток кода для получения токена доступа 'redirect uri' не указан в списке указанных URL

Question

Перед добавлением, да, это работает, когда я даю весь URL, например, http://localhost: 8080 / onedrive / oauth2 / success / 1 в списке URI в azure URIS. Я использую поток кода для авторизации этих токенов. Но в соответствии с документами, это должно работать со мной, просто упомянув там доменное имя, например http://localhost: 8080 . Что это не так.

Я хочу сделать что-то вроде отправки идентификатора пользователя вместе с каждым запросом, чтобы я отслеживал, к какому пользователю я должен связать этот токен доступа, и не знаю, как это сделать, если эта проблема есть. Моя текущая прикладная логика c такова, что когда мое приложение отправляет данные пользователя и вызывает мой Spring API, я хочу обработать всю эту передачу токенов на стороне сервера, поэтому я хочу передать этот userId в качестве переменной пути. Как мне go сделать это? Кто-нибудь сделал это, могут ли они объяснить мне другое решение?

Answer 1

Если вы передаете URI перенаправления как http://localhost: 8080 / , то это означает, что вы обрабатываете ответ API в

/

конечная точка, а не

/ onedrive / oauth2 / success / 1

Чтобы узнать пользователя, с которым вы ссылаетесь, есть несколько идей, которые вы можете использовать:

1) Использование защиты для получения учетных данных вошедшего в систему пользователя (например, Принципал, если вы используете безопасность Spring в java)

2) После успешной аутентификации используйте свой идентификатор пользователя и отправить еще один запрос к бэкэнду и сохранить его в базе данных с идентификатором пользователя в качестве ключа

Answer 2

Вы не можете добавлять пользовательские данные в перенаправления OAuth, и рекомендуется всегда регистрировать полный URI перенаправления.

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

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