REST API Office 365 — Возвращение значения NULL (только для определенных пользователей)
Я тяну волосы за это, может, у кого-то есть идея. У нас есть веб-приложение, зарегистрированное в Azure, которое получает данные календаря и событий из API Office 365, которые относятся к учетной записи пользователя, вошедшего в систему.
Когда пользователь входит в нашу систему, мы получаем токен обновления и получаем токены + ID из API Office365. Я могу отправить токен доступа непосредственно на сервер, и я могу видеть события пользователей, все работает правильно. «Базовый» код oauth взят из примера кода Вот . Мы также можем сделать это из нашего приложения, и оно также работает должным образом.
Это работает правильно для определенных пользователей, но не для других пользователей. Для этих пользователей система аутентифицирует их токен, но отвечает значением NULL в ключе «value» в ответе.
- Типы подписки между работающими и неработающими пользователями идентичны (E1).
- Код, который обрабатывает вызовы, не изменяется, нет никакого дополнительного процесса, через который проходят «определенные пользователи». Все они одинаково воспринимаются нашей локальной системой.
- Нет никаких экологических или переменных различий. Некоторые учетные записи будут получать свои события, другие получают нулевой ответ. Даже на одном компьютере.
- В каждом случае есть действительные события календаря или сообщения.
Вот точный ответ сервера, который происходит после аутентификации токена доступа:
(string(196) "{"@odata.context":"https : //outlook.office.com/api/v1.0/$metadata#Me/Events","value":[{"error":{"code":"ErrorInternalServerError","message":"Object reference not set to an instance of an object."}}")
(пробелы добавлены после https из-за репутации)
Если я войду как пользователь в песочнице oauth (https://oauthplay.azurewebsites.net/) система будет возвращать правильные результаты в каждом случае. Это заставляет меня полагать, что маркер доступа, который передает нам Office365, неверен, но, похоже, он выходит из строя только в определенных ситуациях, когда между этими пользователями нет общей связи.
Я пытаюсь найти любую возможную причину, по которой это может произойти. Если у кого-то есть идеи, я весь в ушах.
Решение
Не имея слишком много подробностей, исходя из того, что вы описали, я думаю, что это связано с тем, как вы зарегистрировали свое приложение для взаимодействия с Azure AD. В некоторых случаях пользователи, которые не принадлежат к одному и тому же лицу Azure AD Tenancy, зарегистрированному в приложении (или зарегистрированы для возможности использования приложения), приводят к созданию сгенерированных токенов доступа на начальном этапе OAuth, но при использовании с другим Azure. AD APIs, эти токены не работают. Для получения дополнительной информации, посмотрите на Эта статья (документация о том, что это означает, довольно скудна. Обратите внимание, что для включения многопользовательского режима в консоли управления Azure вам необходимо зарегистрировать полное доменное имя (FQDN)).
Тем не менее, это может вообще не быть вашей проблемой — я бы порекомендовал вам предоставить любую другую информацию о характере учетных записей, на которых работает аутентификация, и о характере тех учетных записей, на которых она не работает.
Другие решения
Ну, я не нашел хорошего ответа относительно того, почему это произошло, но мы изменили конечную точку вместо / events / на / calendarview /? {Params}, и все, казалось, работало как волшебство.
Зная это, мне было бы интересно узнать, почему / events / работает только для определенных пользователей, а не для других. Может быть, это поможет кому-то в будущем.