我在企业环境中拥有这个 Azure Function 应用程序，该应用程序已经存在相当长一段时间了，并且似乎按预期工作。 它使用用户管理的身份；除此之外，它还允许它访问存储资源。
到目前为止，一切都运行良好，因为该 Function 应用程序是由 Http 触发器或服务总线触发器触发的，并访问一些 API 来执行任务。
现在我一直在尝试为其添加耐用功能。失败!
对该函数的 http 调用有效，并且该函数开始执行其内部操作，但最终失败。端到端调用在这些类型的内部调用上显示错误 403 和 409:
- XXX.blob.core.windows.net PUT
- XXX.表.core.windows.net POST
- XXX.队列.core.windows.net POST
这让我想知道:我的用户身份的权限是否足够？
我可以在存储资源的 IAM 中看到该身份确实具有以下角色:
- 存储 Blob 数据贡献者
- 存储队列数据贡献者
- 存储表数据贡献者
我对这一切的知识库是这个手册页:https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-configure-durable-functions-with-credentials 该页面似乎证实了这些角色就足够了。
我的方向正确吗？
最佳答案
第二天，该问题“自行解决”。
它可能已通过以下软件包之一的不相关升级得到解决:
- Microsoft.Azure.Functions.Extensions 升级至 1.1.0
- Microsoft.Azure.WebJobs.Extensions 4.0.1
不幸的是，我无法提供以前的版本(导致问题的版本)。
不过，我在 StackOverflow 上发现了一篇文章，其中有人通过为托管身份赋予“过度杀戮”角色来解决类似的问题。我的意思是，对于文档规定的最小角色来说，有些过分了。
这让我觉得函数库中的某个时刻可能存在错误，该错误已被修复。
要么是这样，要么是 Azure 应用更改或部署资源时出现了奇怪的延迟(但 24 小时似乎很疯狂)。
抱歉，我无法提供更多信息。
关于Azure 持久功能 : 403 and 409 errors when writing internally to blob/queue/table. 我需要 "Storage Account Contributor"吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/77095628/