Получить общий календарь от разных пользователей (конференц-зал)

Question

// Как получить различные события календаря для пользователей/конференц-залов?

Мы пытаемся использовать API-интерфейс REST для получения событий календаря другого пользователя (общий календарь для аутентифицированного пользователя) или конференц-зал (должен быть пользователем Active Directory с общим календарем для всех пользователей организации).

Мы по-прежнему получаем ответ «Запретный».

Мы можем успешно получить пользовательские события календаря.

Мы также можем получить информацию о пользователях, прошедших проверку подлинности, и даже другого пользователя (пользователя, аутентифицированного как John.Doe@company.com, и можете получить информацию о пользователе elise@doe.company.com), но мы не можем получить подробную информацию о пользователь конференц-зала, хотя он должен быть обычным пользователем в нашей AD.

Мы попытались настроить все делегированные и даже разрешенные приложения области, ничего не помогло.

Пример: вар конечная точка = "https://graph.microsoft.com/v1.0/users/ "+ + идентификатор пользователя"/ calendarView";

Есть ли способ получить эту информацию?

Answer 1

Проблема в том, что ваш токен не имеет правильной области. Чтобы иметь доступ к общим календарям, вам нужен Calendars.Read.Shared (или Calendars.ReadWrite.Shared). Как вы получаете, что сфера в ваш знак зависит от того, где вы зарегистрировали приложение (которое отвечает на первый вопрос!)

1. Имеет ли значение, где и как заявка была зарегистрирована?

   Да, это важно. Оба метода будут работать, но там, где вы регистрируете, влияет на то, как вы запрашиваете авторизацию и токены. Кроме того, приложения, зарегистрированные в Azure Management Portal, могут только аутентифицировать пользователей Office 365, а не пользователей Outlook.com. Подробнее об этом в № 2.

2. Неважно, какой идентификационный URL мы используем?

   Да! Используемый вами URL напрямую связан с местом, где вы зарегистрировали свое приложение. Я собираюсь сломать это ниже.

3. Разрешения области приложения против делегированных разрешений на область - неважно, какие из них мы установили в приложении? Будет ли наша желаемая функциональность работать с делегированными разрешениями?

   Да, это важно. Разрешения приложений предоставляются приложению, а для API Outlook они являются глобальными для всей организации. Поэтому, если вы предоставляете приложение Mail.Read, оно может читать почту для всех пользователей в организации. Приложение действует как само по себе и не аутентифицирует пользователя. Из-за этого для метода auth требуется сертификат вместо секретности клиента. Этот метод предназначен для приложений типа daemon. Вы, скорее всего, хотите делегировать разрешения, так как хотите аутентифицировать пользователей, а затем предоставить им доступ только к тем другим почтовым ящикам/календарям, которые им разрешено просматривать.

4. Разрешения AD каким-то образом влияют на разрешения, которые пользователь имеет в приложении?

   Ну да, в том смысле, что если вы включаете в свои разрешения область .Shared, то у пользователя есть доступ к тому, что другие пользователи поделились с ними (и это связано с AD).

Как добавить общий объем

Как я уже говорил выше, это имеет значение, как вы зарегистрировали свое приложение.

Azure Management Portal

приложения, зарегистрированные в портале управления Azure использовать "v1" вариант реализации oauth2 Azure в. В соответствии с этой моделью вы должны указать разрешения для своего приложения «вверх» на самой регистрации приложения. Чтобы добавить общее разрешение, вам необходимо изменить регистрацию приложения на портале. Разрешения отображаются на портале как «Чтение пользовательских и общих календарей» (для Calendars.Read.Shared) и «Чтение и запись пользовательских и общих календарей» (для Calendars.ReadWrite.Shared).

Если ваше приложение регистрируется здесь, то вы должны использовать v1 AUTH и маркер конечных точек:

https://login.microsoftonline.com/common/oauth2/authorize 
https://login.microsoftonline.com/common/oauth2/token 

Кроме того, по схеме v1, если вы добавляете новую область действия для регистрации на приложении, вы должны иметь пользовательский повтор. В противном случае, в следующий раз, когда они войдут в ваше приложение, они просто получат те же разрешения, что и раньше. Для этого при отправке пользователей в конечную точку авторизации добавьте параметр prompt=consent в URL авторизации.

Применение Регистрация Портал

приложения зарегистрированные здесь использовать v2 Azure реализацию и получить несколько преимуществ. Во-первых, вы можете аутентифицировать учетные записи Microsoft (Outlook.com), а также пользователей Office 365. Во-вторых, добавление областей не требует изменения регистрации вашего приложения. И, наконец, вам не нужно вручную повторять пользователей, конечная точка auth обнаружит изменение и предложит вам.

приложение зарегистрированное здесь использует v2 авторизацию и маркер конечных точки:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize 
https://login.microsoftonline.com/common/oauth2/v2.0/token 

Область применение указаны в параметре scope URL в Идентой конечной точке. Чтобы добавить общие области, вы просто замените существующие Calendars.Read и/или Calendars.ReadWrite эквивалентом .Shared.