0

我正在使用来自 MS GRAPH 的邀请 API -邀请链接

发送共享邀请 – 外部用户

  • POST /me/drive/items/{item-id}/invite
  • POST /sites/{siteId}/drive/items/{itemId}/invite

上述请求的响应返回 200 OK 响应码并返回一个权限对象,但链接对象下的共享链接(webUrl)大多数时候返回“null”,导致无法将可共享链接共享给外部用户编辑文档。

请求正文:



    {
    "recipients": [
        {
          "email": "abc@abc.com"
        }
      ],
      "message": "Here's the file that we're collaborating on.",
      "requireSignIn": true,
      "sendInvitation": false,
      "roles": [ "write" ]
    }

在这里,我不想通过邮件共享项目,因此将 sendInvitation 设为 false 并使用从响应中收到的 webURL 进行协作。

观察:它适用于 gmail 和 Outlook 帐户。对于企业帐户,它无法将 url 接收为空。

样品:

  • 如果我是第一次邀请,我会收到以下回复,

例外响应示例:

{
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(permission)",
    "value": [
        {
            "@odata.type": "#microsoft.graph.permission",
            "roles": [
                "write"
            ],
            "grantedToIdentities": [
                {
                    "user": {
                        "email": "#####@####.com"
                    }
                }
            ],
            "invitation": {
                "signInRequired": true
            },
            "link": {
                "type": "edit",
                "webUrl": "https://**********encryptedURL*****/"
            }
        }
    ]
}

  • 从第二次没有响应的链接对象开始,

收到没有 webURL 的示例响应:

{
    "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(permission)",
    "value": [
        {
            "@odata.type": "#microsoft.graph.permission",
            "id": "###############",
            "roles": [
                "write"
            ],
            "grantedTo": {
                "user": {
                    "email": "######@######.com",
                    "id": "#############",
                    "displayName": "@@@@@@@"
                }
            }
        }
    ]
}

4

1 回答 1

0

我通过使用上传 API LINK解决了我的问题 ,一旦上传成功,API 将返回响应,该响应将具有“webUrl”链接,可用于第二次共享。

(在使用 MS GRAPH API 进行更多探索后发现,如果我们多次共享同一个文件,它将不会提供任何新链接,因为只能使用旧链接)

实际流程:上传文件->共享文件(每次都发生这种情况)

更改逻辑:第一次:上传文件 -> 共享文件

第二次开始:因为文件已经共享,使用上传 API 响应中的 url

由于文件已经第一次与用户共享,因此可以使用我们从 UPLOAD API 获得的响应的 url,这个 url 可以被已经共享的用户访问。

所以我改变了我的逻辑,如果用户第一次执行该操作,那么我正在上传文件并与他共享,如果用户想要再次执行相同的操作而不是使用它适用于我的上传响应 url 再次共享文件。

发布此解决方案,因为它可能对某人有所帮助

于 2020-09-15T07:16:31.090 回答