日历 ID 随机更改 [英] Calendar Id randomly changed

问题描述

使用microsoft graph时，日历更改其id的原因是什么???

今天我们的一位客户发生了这种情况，他使用了他的主日历超过 2 年，今天突然，ID 发生了变化，我们无法添加任何事件，因为我们拥有旧"ID

被调用的端点:

/me/calendars/AAMkAGFmMzAxNmRkLTg4YTEtNDNhZS1iYjExLWE1OThlYThlNTRmOQBGAAAAAACxNL6zUoo_Qr9AY8vFoIfmBwBstbpyrelbSJu1keAu6bGABAAAbAAAaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaacaaaaaaaaaaaaaaaaaaabo

返回错误:

{错误":{代码":ErrorItemNotFound"，消息":在存储中未找到指定的对象."}}

标题:

{缓存控制":[私人"],内容类型":["应用程序/json;odata.metadata=最小；odata.streaming=true;IEEE754Compatible=false;字符集=utf-8"],请求 ID":[63353567-4ebd-4b25-903b-d66717797882"],客户端请求 ID":[63353567-4ebd-4b25-903b-d66717797882"],x-ms-ags-诊断":["{\"ServerInfo\":{\"DataCenter\":\"North Europe\",\"Slice\":\"SliceC\",\"Ring\":\"4\",\"ScaleUnit\":\"001\",\"RoleInstance\":\"AGSFE_IN_6\"}}"],严格的运输安全":[最大年龄=31536000"],日期":[格林威治标准时间 2021 年 2 月 4 日星期四 10:40:39"],内容长度":[99"]}

新日历 id:AAMkAGFmMzAxNmRkLTg4YTEtNDNhZS1iYjExLWE1OThlYThlNTRmOQBGAAAAAACxNL6zUoo_Qr9AY8vFoIfmBwBstbpyrelbSJu1keAu6bMkAAAAaaelbgAfl>Ju1keAu6bMkAAAAAebGamagebMkAAAAAebGAFQLWE1OThlYThlNTRmOQBGAAAAAACxNL6zUoo_Qr9AY8vFoIfmBwBstbpyrelbS

编辑:(发生在另一个客户身上)今天又发生在另一个客户(另一个租户 ID)上，详情如下:

旧日历 ID:

AAMkAGI2Y2NkYzVmLTc3ZjUtNDQyNi1iNjIzLTljNjkyMDk5YjEyYwBGAAAAAADQqVqZh-ZpQJl-EcoJBivzBwCE3CCn1SYkSLnEBiNMaH3ZAAAEyYwBGAAAAAADQqVqZh-ZpQJl-EcoJBivzBwCE3CCn1SYkSLnEBiNMaH3ZAAAEBAAAiH3ZAAAEyYwBGAAAAaaaaaaaaabc

{缓存控制":[私人"],内容类型":["应用程序\/json;odata.metadata=最小；odata.streaming=true;IEEE754Compatible=false;字符集=utf-8"],请求 ID":[2f9ddb93-3594-4d86-97f9-d7dbe960a2bb"],客户端请求 ID":[2f9ddb93-3594-4d86-97f9-d7dbe960a2bb"],x-ms-ags-诊断":["{\"ServerInfo\":{\"DataCenter\":\"North Europe\",\"Slice\":\"SliceC\",\"Ring\":\"4\",\"ScaleUnit\":\"001\",\"RoleInstance\":\"AGSFE_IN_71\"}}"],严格的运输安全":[最大年龄=31536000"],日期":[格林威治标准时间 2021 年 2 月 8 日星期一 11:08:53"],内容长度":[99"]}

新日历 ID:

AAMkAGI2Y2NkYzVmLTc3ZjUtNDQyNi1iNjIzLTljNjkyMDk5YjEyYwBGAAAAAADQqVqZh-ZpQJl-EcoJBivzBwCE3CCn1SYkSLnEBiNMaH3ZAAABAAAiGAPACE=AAMkAGI2Y2NkYzVmLTc3ZjUtNDQyNi1iNjIzLTljNjkyMDk5YjEyYwBGAAAAAADQqVqZh-ZpQJl-EcoJBivzBwCE3CCn1SYkSLnEBiNMaH3ZAAAZAAAiGACE=

解决方案

这是一个难题...那些看起来是 Base64 编码的.如果您对旧 ID 和新 ID 进行 Base 64 解码，您会发现其中嵌入了相同的 GUID.

(使用 https://www.base64decode.org/)

旧解码:$af3016dd-88a1-43ae-bb11-a598ea8e54f9F4R?B@cŠlr[H.$lr[H.$P|新解码:$af3016dd-88a1-43ae-bb11-a598ea8e54f9F4R?B@cŠlr[H.$lr[H.$|H(指南:af3016dd-88a1-43ae-bb11-a598ea8e54f9)——提供了第二个例子旧解码:$b6ccdc5f-77f5-4426-b623-9c692099b12cFЩZi@~ + &$H#Lh} &$H#Lh}<新解码:$b6ccdc5f-77f5-4426-b623-9c692099b12cFЩZi@~ + &$H#Lh} &$H#Lh}6(指南:b6ccdc5f-77f5-4426-b623-9c692099b12c)

如果无法通过图形请求中的查询使用嵌入的 GUID，则可以调用 https://graph.microsoft.com/v1.0/me/calendars，解码所有日历，找到具有匹配嵌入式 GUID 的 ID，然后使用那个?它会添加一个额外的调用，但您可能可以在异常处理中执行此操作，因为不需要状态.这可能对您现有的应用程序有所帮​​助.

我不能保证这会起作用，因为我没有随时间推移的数据来测试这个理论......但你做:)

为了避免 ID 更改出现此问题，请考虑存储 尽可能不可变的 ID.您无法将它们存储在容器(日历、邮箱等)中，但也许可以继续为应用程序创建的事件存储它们，以便您可以从那里向后工作.

<块引用>

容器类型(邮件文件夹、日历等)不支持不可变 ID，但它们的常规 ID 已经是恒定的.

他们文档中的这一行值得注意，因为您的体验与他们的文档声明不符.这让您可以向 MS 投诉，或向您的客户投诉 IBM(IBM:我怪微软).

此外，我会问两个组织的 IT 是否更改了与 AAD 同步或 Exchange 相关的任何内容?我有一个与此相关的疯狂理论.最近有一封电子邮件要求人们更新 AAD 同步，而这种模式对于某种身份验证提供程序的更改感觉很熟悉.

Whats the reason that make a calendar change it's id when using microsoft graph ???

This happened today for one of our clients who's been using his main Calendar for over 2 years, and suddenly today, the id is changed and we are unable to add any event since we have the 'old' id

Endpoint being called:

/me/calendars/AAMkAGFmMzAxNmRkLTg4YTEtNDNhZS1iYjExLWE1OThlYThlNTRmOQBGAAAAAACxNL6zUoo_Qr9AY8vFoIfmBwBstbpyrelbSJu1keAu6bMkAAAAAAEGAABstbpyrelbSJu1keAu6bMkAAAAAFB8AAA=/events

Error returned:

{
  "error": {
    "code": "ErrorItemNotFound",
    "message": "The specified object was not found in the store."
  }
}

Headers:

{
  "Cache-Control": [
    "private"
  ],
  "Content-Type": [
    "application/json; odata.metadata=minimal; odata.streaming=true; IEEE754Compatible=false; charset=utf-8"
  ],
  "request-id": [
    "63353567-4ebd-4b25-903b-d66717797882"
  ],
  "client-request-id": [
    "63353567-4ebd-4b25-903b-d66717797882"
  ],
  "x-ms-ags-diagnostic": [
    "{\"ServerInfo\":{\"DataCenter\":\"North Europe\",\"Slice\":\"SliceC\",\"Ring\":\"4\",\"ScaleUnit\":\"001\",\"RoleInstance\":\"AGSFE_IN_6\"}}"
  ],
  "Strict-Transport-Security": [
    "max-age=31536000"
  ],
  "Date": [
    "Thu, 04 Feb 2021 10:40:39 GMT"
  ],
  "Content-Length": [
    "99"
  ]
}

New calendar id: AAMkAGFmMzAxNmRkLTg4YTEtNDNhZS1iYjExLWE1OThlYThlNTRmOQBGAAAAAACxNL6zUoo_Qr9AY8vFoIfmBwBstbpyrelbSJu1keAu6bMkAAAAAAEGAABstbpyrelbSJu1keAu6bMkAAF8qLRIAAA=

Edit: (Happened for another client) It happened again today with another client (another tenant-id), here are details:

Old calendar id:

AAMkAGI2Y2NkYzVmLTc3ZjUtNDQyNi1iNjIzLTljNjkyMDk5YjEyYwBGAAAAAADQqVqZh-ZpQJl-EcoJBivzBwCE3CCn1SYkSLnEBiNMaH3ZAAAAAAEGAACE3CCn1SYkSLnEBiNMaH3ZAAAAAB08AAA=

{
   "Cache-Control":[
      "private"
   ],
   "Content-Type":[
      "application\/json; odata.metadata=minimal; odata.streaming=true; IEEE754Compatible=false; charset=utf-8"
   ],
   "request-id":[
      "2f9ddb93-3594-4d86-97f9-d7dbe960a2bb"
   ],
   "client-request-id":[
      "2f9ddb93-3594-4d86-97f9-d7dbe960a2bb"
   ],
   "x-ms-ags-diagnostic":[
      "{\"ServerInfo\":{\"DataCenter\":\"North Europe\",\"Slice\":\"SliceC\",\"Ring\":\"4\",\"ScaleUnit\":\"001\",\"RoleInstance\":\"AGSFE_IN_71\"}}"
   ],
   "Strict-Transport-Security":[
      "max-age=31536000"
   ],
   "Date":[
      "Mon, 08 Feb 2021 11:08:53 GMT"
   ],
   "Content-Length":[
      "99"
   ]
}

New calendar id:

AAMkAGI2Y2NkYzVmLTc3ZjUtNDQyNi1iNjIzLTljNjkyMDk5YjEyYwBGAAAAAADQqVqZh-ZpQJl-EcoJBivzBwCE3CCn1SYkSLnEBiNMaH3ZAAAAAAEGAACE3CCn1SYkSLnEBiNMaH3ZAAGPkTa6AAA=

解决方案

Here's a piece of the puzzle... Those look Base64 encoded. If you Base 64 decode the old and the new IDs, you'll find the same GUIDs are embedded inside it.

(Use https://www.base64decode.org/)

Old decoded: $af3016dd-88a1-43ae-bb11-a598ea8e54f9F4R?B@cŠlr[H.$lr[H.$P|
New decoded: $af3016dd-88a1-43ae-bb11-a598ea8e54f9F4R?B@cŠlr[H.$lr[H.$|H
(guid: af3016dd-88a1-43ae-bb11-a598ea8e54f9)
- 
2nd example provided 
Old decoded: $b6ccdc5f-77f5-4426-b623-9c692099b12cFЩZi@~    + &$H#Lh} &$H#Lh}<
New decoded: $b6ccdc5f-77f5-4426-b623-9c692099b12cFЩZi@~    + &$H#Lh} &$H#Lh}6
(guid: b6ccdc5f-77f5-4426-b623-9c692099b12c)

If it is not possible to use the embedded GUID via a query in the graph request, then maybe call https://graph.microsoft.com/v1.0/me/calendars, decode all the calendars, find the ID with the matching embedded GUID, and use that one? It would add an extra call, but you might be able to do it in exception handling, as no state is required. This may help with your existing application.

I can't guarantee this would work as I don't have data over time to test this theory with... but you do :)

To avoid this issue with ID changes going forward, look into storing immutable IDs wherever possible. You cannot store them for containers (calendars, mailboxes, etc), but perhaps moving forward you can store them for the events that your application creates, so you can work backwards from there.

Container types (mailFolder, calendar, etc.) do not support immutable ID, but their regular IDs were already constant.

This line from their documentation is notable, as your experience does not match what their documentation states. This opens scope for you to complain to MS, or lodge an IBM with your customers (IBM: I Blame Microsoft).

Also, I'd be asking IT in both orgs if they changed anything related to AAD Sync or Exchange? I have got a wild theory it's related to that. There was an email that went out recently asking people to update AAD sync, and this pattern just feels familiar to some sort of auth provider change.

这篇关于日历 ID 随机更改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！