【问题标题】:Get shared calendar from different user(meeting room)从不同用户(会议室)获取共享日历
【发布时间】:2016-12-19 10:16:51
【问题描述】:

// 如何获取不同的用户/会议室日历事件?

我们正在尝试使用图形 REST API 来获取另一个用户(与经过身份验证的用户共享日历)或会议室(应该是与组织内所有用户共享日历的 Active Directory 用户)的日历事件。

我们仍然收到“禁止”响应。

我们可以成功获取用户(他自己)认证的日历事件。

我们还可以获取经过身份验证的用户甚至另一个用户的用户详细信息(用户身份验证为 John.Doe@company.com,并且可以获取 elise@doe.company.com 的用户详细信息),但我们无法获取会议室用户,即使它应该是我们 AD 中的普通用户。

我们尝试设置所有委派甚至应用权限范围,但没有任何帮助。

示例: var endpoint = "https://graph.microsoft.com/v1.0/users/"+userId+"/calendarView";

有没有办法检索这些信息?

【问题讨论】:

  • 对此有任何更新吗?我遇到了同样的问题
  • 不 :( 对不起。仍然卡住 :/
  • 能否发布您尝试访问的完整 URL 以及 403 的响应标头?
  • @JasonJohnston 带有测试 API 的应用程序是:mere.azurewebsites.net 调用:graph.microsoft.com/v1.0/users/john.doe@company.com/…"
  • @JasonJohnston 响应:{StatusCode:403,ReasonPhrase:'Forbidden',版本:1.1,内容:System.Net.Http.StreamContent,标头:{ Transfer-Encoding:chunked request-id:03445f6e -de11-42c3-a396-69c7b43ab215 client-request-id: 03445f6e-de11-42c3-a396-69c7b43ab215 x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"West Europe","Slice": "SliceB","ScaleUnit":"003","Host":"AGSFE_IN_4","ADSiteName":"AMS"}} 持续时间:191.0259 缓存控制:私有日期:2017 年 1 月 25 日星期三 13:02:05 GMT服务器:Microsoft-IIS/8.5 X-Powered-By:ASP.NET 内容类型:application/json }}

标签: c# asp.net-mvc microsoft-graph-api outlook-restapi


【解决方案1】:

问题是您的令牌没有正确的范围。为了能够访问共享日历,您需要Calendars.Read.Shared(或Calendars.ReadWrite.Shared)。您如何将该范围纳入您的令牌取决于您在哪里注册应用程序(这回答了您的第一个问题!)

  1. 申请注册的地点或方式是否重要?

    是的,这很重要。这两种方法都可以,但是您注册的位置会影响您请求授权和令牌的方式。此外,在 Azure 管理门户中注册的应用只能对 Office 365 用户进行身份验证,而不能对 Outlook.com 用户进行身份验证。更多信息请参见 #2。

  2. 我们使用什么身份验证 URL 重要吗?

    是的!您使用的 URL 与您注册应用的位置直接相关。我将在下面对此进行分解。

  3. 应用范围权限与委派范围权限 - 我们在应用程序中设置哪些权限是否重要?我们想要的功能是否可以与委派的权限一起使用?

    是的,这很重要。应用程序权限被授予应用程序,对于 Outlook API,这些权限对整个组织都是全局的。因此,如果您授予应用程序Mail.Read,它可以阅读组织中所有用户的邮件。该应用程序充当其自身,并且不对用户进行身份验证。因此,auth 方法需要证书而不是客户端密码。此方法适用于守护程序类型的应用程序。您很可能需要委派权限,因为您想对用户进行身份验证,然后只授予他们访问允许他们查看的其他邮箱/日历的权限。

  4. AD 权限是否会以某种方式影响用户在应用程序中的权限?

    是的,从某种意义上说,如果您在权限中包含 .Shared 范围,则用户有权访问的内容由其他用户与他们共享的内容设置(这与 AD 相关联)。

如何添加共享范围

正如我上面所说,这对你如何注册你的应用很重要。

Azure 管理门户

在 Azure 管理门户中注册的应用使用 Azure 的 OAuth2 实施的“v1”版本。在此模型下,您必须在应用注册本身“预先”指定您的应用的权限。要添加共享权限,您必须在门户中修改应用注册。权限在门户中显示为“读取用户和共享日历”(对于 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。

应用程序注册门户

在此处注册的应用使用 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

范围在 auth 端点的 scope URL 参数中指定。因此,要添加共享范围,您只需将现有的 Calendars.Read 和/或 Calendars.ReadWrite 替换为等效的 .Shared

【讨论】:

  • 非常感谢Jason,您的回答帮助了我们!现在我们终于可以得到一些东西并开始使用它了。但是,我们很快遇到了另一个问题,请您尝试看看它并提供更多帮助吗?我们编辑了原始问题
  • 如果您再发布一个问题以避免混淆会更好。
猜你喜欢
  • 2016-09-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-11-06
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多