Получить общий календарь от другого пользователя (переговорная)

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

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

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

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

Мы также можем получить сведения об аутентифицированном пользователе и даже о другом пользователе (пользователь аутентифицирован как [email protected] и может получить данные пользователя [email protected]), но мы не можем получить данные о пользователе конференц-зала. хоть это и должен быть нормальный пользователь в нашей AD.

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

Пример: var endpoint = "https://graph.microsoft.com/v1.0/users/ "+ userId +" / calendarView ";

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


person Jiri    schedule 19.12.2016    source источник
comment
были ли обновления к этому? Я столкнулся с той же проблемой   -  person Tony    schedule 05.01.2017
comment
нет :( простите. Все еще застрял: /   -  person Jiri    schedule 20.01.2017
comment
Не могли бы вы опубликовать полный URL-адрес, к которому вы пытаетесь получить доступ, и заголовки ответов из вашего 403?   -  person Jason Johnston    schedule 24.01.2017
comment
@JasonJohnston Приложение с api тестирования: plain.azurewebsites.net Звонок: graph.microsoft.com/v1.0/users/[email protected]/   -  person Jiri    schedule 25.01.2017
comment
@JasonJohnston Response: {StatusCode: 403, ReasonPhrase: 'Forbidden', Version: 1.1, Content: System.Net.Http.StreamContent, Headers: {Transfer-Encoding: chunked request-id: 03445f6e-de11-42c3-a396-69c7b43ab215 идентификатор-запроса-клиента: 03445f6e-de11-42c3-a396-69c7b43ab215 x-ms-ags-diagnostics: {ServerInfo: {DataCenter: West Europe, Slice: SliceB, ScaleUnit: 003, Host: AGSFE_IN_4, ADSiteName: AMS}} Продолжительность : 191.0259 Cache-Control: private Дата: среда, 25 января 2017 г., 13:02:05 GMT Сервер: Microsoft-IIS / 8.5 X-Powered-By: ASP.NET Content-Type: application / json}}   -  person Jiri    schedule 25.01.2017
comment
Ok. Я предполагаю, что у вашего токена нет необходимых областей действия. Используйте парсер JWT (например, jwt.calebb.net) и проанализируйте токен доступа, который вы используете. Вы ищете значение поля scp.   -  person Jason Johnston    schedule 25.01.2017
comment
Привет, @JasonJohnston, спасибо за ответ. scp: Календари.Читать календари.Читать.Написать контакты................................................................. 1. Имеет ли значение, где и как было зарегистрировано приложение? Это можно сделать либо в apps.dev.microsoft.com, либо в консоли управления Azure manage.windowsazure.com   -  person Jiri    schedule 26.01.2017
comment
@JasonJohnston Часть 2: 2. Имеет ли значение, какой URL для аутентификации мы используем? Существуют ли какие-либо параметры, которые могут повлиять на разрешения, что приведет к проблеме FOrbidden, с которой мы сталкиваемся? 3. Разрешения области действия приложения и разрешения делегированной области - имеет ли значение, какие из них мы настроили в приложении? Будет ли наша желаемая функциональность работать с делегированными разрешениями? 4. Влияют ли каким-либо образом права доступа AD на права доступа пользователя к приложению?   -  person Jiri    schedule 26.01.2017


Ответы (1)


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

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

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

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

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

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

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

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

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

Как добавить общую область

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

Портал управления Azure

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

Если ваше приложение зарегистрировано здесь, вы ДОЛЖНЫ использовать конечные точки аутентификации и токена v1:

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

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

Портал регистрации приложений

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

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

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

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

person Jason Johnston    schedule 26.01.2017
comment
Большое спасибо Джейсон, ваш ответ нам помог! Теперь мы наконец можем что-то получить и начать с этим работать. Однако мы быстро сталкиваемся с другими проблемами, не могли бы вы взглянуть на это и помочь еще немного, пожалуйста? Мы отредактировали исходный вопрос - person Jiri; 30.01.2017
comment
Было бы лучше, если бы вы разместили еще один вопрос, чтобы избежать путаницы. - person Jason Johnston; 30.01.2017