Office 365 REST API - значение, возвращающее NULL (только для определенных пользователей)

Я рву над этим за волосы, может, у кого-то есть идея. У нас есть веб-приложение, зарегистрированное в Azure, которое получает данные календаря и событий из API Office 365, относящиеся к учетной записи пользователя, вошедшего в систему.

Когда пользователь входит в нашу систему, мы получаем токен обновления и доступ к токенам + ID из API Office365. Я могу отправить токен доступа прямо на сервер, и я могу видеть события пользователей, все работает правильно. "Базовый" код oauth взят из примера кода, который здесь. Мы также можем сделать это из нашего приложения, и оно также работает правильно.

Это работает правильно для определенных пользователей, но не для других пользователей. Для этих пользователей система аутентифицирует их токены, но при ответе возвращает значение NULL в ключе «value».

  • Типы подписки между работающими и неработающими пользователями идентичны (E1).
  • Код, обрабатывающий вызовы, не меняется, нет дополнительных процессов, которые проходят "определенные пользователи". Все они обрабатываются нашей локальной системой одинаково.
  • Нет никаких экологических или переменных различий. Некоторые учетные записи будут получать свои события, другие получают ответ NULL. Даже на одном компьютере.
  • В каждом случае есть действующие календарные события или сообщения.

Мы получаем точный ответ сервера, который происходит после аутентификации токена доступа:

(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, неверен, но кажется, что он не работает только в определенных ситуациях, когда между этими пользователями нет общей связи.

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


person Girl    schedule 11.09.2015    source источник


Ответы (2)


Не вдаваясь в подробности того, что вы описали, я предполагаю, что это проблема, связанная с тем, как вы зарегистрировали свое приложение для взаимодействия с Azure AD. В некоторых случаях пользователи, которые не принадлежат к той же клиентской среде Azure AD, которая зарегистрирована в приложении (или зарегистрированы для использования приложения), будут генерировать токены доступа через начальную фазу OAuth, но при использовании против другой Azure. AD API, эти токены не работают. Для получения дополнительной информации ознакомьтесь с этой статьей (документация по это означает несколько редкость.Обратите внимание, что для включения мультитенантности в консоли управления Azure вам необходимо зарегистрировать полное доменное имя (FQDN).

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

person ilkahnate    schedule 12.09.2015

Что ж, я не нашел хорошего ответа на вопрос, почему это происходит, но мы изменили конечную точку вместо / events / на / calendarview /? {Params}, и все, казалось, работало как по волшебству.

Зная это, мне было бы интересно узнать, почему / events / работает только для определенных пользователей, а не для других. Может быть, это кому-то поможет в будущем.

person Girl    schedule 15.09.2015