标签: microsoft-graph-sdks

Microsoft 将某些 Graph 端点的速率限制为每 10 分钟 10,000 个请求（来源）。如果达到限制，Retry-After标头会指示在发送另一个请求之前要等待多长时间。

这是由 Graph SDK 自动处理的吗？如果没有，呼叫者应该采取什么步骤？

我们在 .NET Core 2.1上运行，在运行以下查询时有时会出现异常“此平台不支持安全二进制序列化”：

await _adClient.Users[userId].AppRoleAssignments.ExecuteAsync();

重新执行查询通常有效，因此满足某些条件，即在后续请求中未尝试（或成功？）二进制序列化？也就是说，如果我重新启动服务，它通常也会对第一个请求起作用。

我们正在使用旧的 AD Graph 客户端，因为 1) Microsoft Graph 客户端尚不完全支持AppRoleAssignments，2) 支持的内容是测试版的一部分，不建议用于生产用途。

完整的调用堆栈如下：

System.Data.Services.Client.BaseAsyncResult.EndExecute<T>(object source, string method, IAsyncResult asyncResult)
System.Data.Services.Client.QueryResult.EndExecuteQuery<TElement>(object source, string method, IAsyncResult asyncResult)
System.Data.Services.Client.DataServiceRequest.EndExecute<TElement>(object source, DataServiceContext context, string method, IAsyncResult asyncResult)
System.Data.Services.Client.DataServiceQuery<TElement>.EndExecute(IAsyncResult asyncResult)
Microsoft.Azure.ActiveDirectory.GraphClient.Extensions.DataServiceContextWrapper+<>c__DisplayClass4c<TSource, TInterface>.<ExecuteAsync>b__4a(IAsyncResult r)
System.Threading.Tasks.TaskFactory<TResult>.FromAsyncCoreLogic(IAsyncResult iar, Func<IAsyncResult, TResult> endFunction, Action<IAsyncResult> endAction, Task<TResult> promise, bool requiresSynchronization)
Microsoft.Azure.ActiveDirectory.GraphClient.Extensions.DataServiceContextWrapper.ExecuteAsync<TSource, TInterface>(DataServiceQuery<TSource> inner)
Microsoft.Azure.ActiveDirectory.GraphClient.AppRoleAssignmentCollection.<ExecuteAsync>b__2()
Merck.SeaMonkey.Api.AzureADApi.Controllers.UserController.GetApplicationRoleAssignments(string userId) in UserController.cs

新的 Microsoft Graph 客户端不是这里的一个选项，尽管我想我们可以下拉到基本 REST 接口，这对我们依赖于图客​​户端的所有重试逻辑、结果解析等有点工作去做。

更新：给出异常的来源，我们假设在序列化 OData 响应中的实体时存在问题。但是，使用 AD Graph Explorer，我们会看到一个非常简单的响应，即空值数组以及指向实体元数据文档的链接。我们通过删除和添加新的应用程序角色分配使问题经常再次发生，但我们不能强制它 100% 可靠地发生。看起来某些状态正在损坏，也许在某些内部缓存中？

给定对特定目录角色的成员的查询，我想返回相应用户的列表。我所拥有的是这样的：

IDirectoryObjectCollectionWithReferencesRequest request = graphServiceClient.directoryRoles(roleId).members().buildRequest();
IDirectoryObjectCollectionWithReferencesPage page = request.select(USER_FIELDS_TO_RETURN).get();
List<DirectoryObject> objects = page.getCurrentPage();
IDirectoryObjectCollectionWithReferencesRequestBuilder builder = page.getNextPage();
while (builder != null) {
    request = builder.buildRequest();
    page = request.select(USER_FIELDS_TO_RETURN).get();
    objects.addAll(page.getCurrentPage());
    builder = page.getNextPage();
}
return objects.stream().filter(o -> o.oDataType.equals("#microsoft.graph.user")).map(o -> new User()).collect(Collectors.toList());

问题出在 return 语句上。仅过滤用户对象（找不到比比较 oDataType 更优雅的方法）并返回带有 o 内容的用户对象：

objects.stream().filter(o -> o.oDataType.equals("#microsoft.graph.user")).map(o -> {
        // the only thing that I could think of is to do some weird
        // serialization/deserialization logic here which is a bad solution
        // for anything other than …

我正在使用@microsoft/microsoft-graph-clientnpm 包与基本 url同步日历事件/me/calendarview/delta。直到几天前它一直运行良好。出于某种原因，每当我在 Outlook.office.com 中创建新日历事件并且我的应用程序同步时，新创建的日历事件都会@removed: {reason: "deleted"}设置该字段。

但是，当我使用 Microsoft Graph Explorer 查找同一个日历事件时，同一个事件没有@removed设置该字段。是否有任何理由让新创建的日历事件看起来像是在同步期间被删除？我正在使用@microsoft/microsoft-graph-client v1.3.0

重建步骤：

1. 通过 POST 使用节点图客户端创建事件 /me/calendar/events
2. 使用/me/calendarview/delta适当的 deltaLink 和访问令牌获取日历事件的增量。
3. 我收到 1 个日历事件，其中包含 3 个字段@odata.type、id和@removed。id 字段与步骤 1 中创建的事件的 id 匹配。

如果您需要更多信息，请告诉我。这影响了我们的一些用户。

更新：我尝试通过调用我在增量同步中收到的/me/events/<id>每个@removed日历条目来验证该事件是否真的被删除来解决此问题。但是，当我通过 microsoft-graph-client 调用该 API 时，它返回 null。如果我通过MSFT Graph Explorer进行相同的 GET 调用，则返回该事件。

问题

• 我目前有一个 Azure Active Directory 应用程序，它有一个 Microsoft Graph Webhook 订阅，用于侦听指定邮箱中的新电子邮件（消息）。
• 订阅有一个计划任务，通过更新请求更新订阅的到期日期。订阅的目标是使用其 MS Graph 提供的 ID。
• 针对此特定订阅的任何 DELETE 或 UPDATE 请求都会失败。 (参见下文‘错误响应’。)

题

• 我意识到这可能与此处提出的问题相同的问题/错误：https : //stackoverflow.com/a/53111286/7902641
• 是否有任何修复/解决方案/或解决方法？
• 如果已经修复或者这是一个完全不同的问题，我可以做些什么来解决这个特定问题？
• 谢谢！

错误响应

{
  "error": {
    "code": "ExtensionError",
    "message": "Operation: Delete; Exception: [Status Code: NotFound; Reason: The subscription with Id 'Q0IzOUZCMTYtMTk4OC00OEZDLUFFQjQtNzI4NTU1MDREMkVDXzQ5RDk2MzI3LUFDRDEtNEE2QS05QTQ1LUYwQ0ZGQjgwNEQ0Qg==' is not found.]",
    "innerError": {
      "request-id": "e83fe463-....-....-....-76eb35e2e697",
      "date": "2019-03-22T02:35:14"
    }
  }
}

额外信息

• Somehow the Microsoft Graph ID for the subscription is...transformed? The original subscription ID is ( 528b79f1-....-....-....-360c0e1149e9 ) and the …

我正在尝试根据我已经有值的二进制扩展属性从 grapi api 检索事件。我已从同一 api 检索到该值，因此我知道存在具有该值的事件。我还知道属性 id 是正确的，因为我将其与 .Expand() 一起使用来获取值。

var value = "BAAAAIIA4AB0xbcQGoLgCAAAAAAwMvfBFvzUAQAAAAAAAAAAEAAAAEZ53uCfQ51AhtRf+FNQjOk=";
var cleanGlobalObjectIdPropertyId = "Binary {6ed8da90-450b-101b-98da-00aa003f1305} Id 0x23";

var events = await client.Users["myuser@example.com"].Events.Request()
    .Filter($"singleValueExtendedProperties/Any(ep: ep/id eq '{cleanGlobalObjectIdPropertyId}' and ep/value eq '{value}')")
    .GetAsync();

这是我得到的错误：

Microsoft.Graph.ServiceException：代码：ErrorInvalidUrlQueryFilter

消息：$filter 的过滤器表达式与单个扩展属性和值限制不匹配。

我使用了与字符串类型的扩展属性相同的过滤器语法，并且效果很好，所以我认为这是一个二进制属性这一事实与问题相关。

我已创建 Outlook 日历订阅。在 Outlook 中编辑重复事件的特定实例时，发送到我的通知 URL 的通知适用于系列主事件（而不是更新的特定实例）。

我正在尝试确定更改是针对系列还是针对特定实例。

有什么方法可以从通知（或系列大师）中找出导致通知的原因吗？

我们有一个 NET Core 3.1 Web 应用程序，其中用户使用Microsoft.Identity.Web包在 Azure AD 中进行身份验证。我们将代表登录用户调用 Microsoft Graph SDK，如此处所述。

登录到应用程序后，一切正常 - 对 Microsoft Graph SDK 的所有调用均成功。但是，大约 30-60 分钟后（我们没有准确计时），用户在我们的应用程序中保持身份验证，但对 Microsoft Graph SDK 的调用失败，并出现以下错误：

IDW10502: An MsalUiRequiredException was thrown due to a challenge for the user.

内部异常有：

Microsoft.Identity.Client.MsalUiRequiredException: No account or login hint was passed to the AcquireTokenSilent call.

然后，用户需要注销应用程序并重新登录，之后对 MS Graph 的调用在 30-60 分钟内再次成功。

任何人都可以阐明这一点吗？

我们的设置

在 appsettings.json 中：

    {
  "AzureAd": {
        "Instance": "https://login.microsoftonline.com/",
        "Domain": "<our-domain-name>",
        "TenantId": "<our-tenant-id>",
        "ClientId": "<our-client-id>",
        "CallbackPath": "/signin-oidc",
        "SignedOutCallbackPath ": …

我正在使用 Graph 在现有团队中创建一个新的私人频道。在此之后，我想在该频道中创建一个新选项卡。在对 tabs 端点执行 POST 时，我几乎总是收到带有消息的 404 NotFound，No active channel found with channel id: 19:690...但在创建私有频道后等待几分钟后，tabs 端点可用，我可以创建选项卡。

如果创建标准频道，这总是成功的。

我可以使用 Graph SDK 和 Graph Explorer 重现这一点。

我可以尝试在使用 Graph SDK 以下列方式创建频道后列出可用选项卡，以便能够查看问题：

    var graphClient = new GraphServiceClient(authProvider);

    var channelRequest = new Channel()
    {
        DisplayName = "Test",
        MembershipType = ChannelMembershipType.Private,
        Members = new ChannelMembersCollectionPage()
        {
          new AadUserConversationMember
          {
            Roles = new List<String>()
            {
                "owner"
            },
            AdditionalData = new Dictionary<string, object>()
            {
                {"user@odata.bind", "https://graph.microsoft.com/v1.0/users('{user-id}')"}
            }
          }
      }
    };

    var channel = await graphClient.Teams[teamId].Channels …

使用 Graph API 创建订阅时，即使我们在访问令牌中有足够的权限，也会收到以下错误。

令牌权限：Calendars.ReadWrite Contacts.ReadWrite Tasks.ReadWrite User.Read profile openid email

{
  "error": {
    "code": "ExtensionError",
    "message": "Operation: Create; Exception: [Status Code: Forbidden; Reason: Access is denied to the requested resource. The user might not have enough permission.]",
    "innerError": {
        "date": "2022-11-30T08:23:03",
        "request-id": "0541655d-83f3-456e-af47-165caf259c76",
        "client-request-id": "0541655d-83f3-456e-af47-165caf259c76"
    }
  }
}

使用的详细信息：

请求网址：

POST https://graph.microsoft.com/v1.0/subscriptions 

请求正文：

{
    "notificationUrl":"<development-url>/notifications/office365/graph/v1",
    "expirationDateTime":"2022-12-03T06:48:06Z",
    "resource":"/me/todo/lists/{taskListId}/tasks",
    "changeType":"created,updated,deleted",
    "clientState":"<client-state>"
}

使用的 API - https://graph.microsoft.com/v1.0/subscriptions（微软文档）

问题影响的用户数 - 190