Dotnet 隔离的 Azure 函数 - 如何访问 HttpContext答案

【问题标题】：Dotnet-Isolated Azure Functions - how to access HttpContextDotnet 隔离的 Azure 函数 - 如何访问 HttpContext
【发布时间】：2026-02-04 20:40:02
【问题描述】：

我有一个由 HTTP 调用触发的 dotnet 5 Azure 函数（dotnet 隔离）。

该函数将由不同的 Azure 函数应用调用，我想使用 Azure AD 保护目标并使用“客户端凭据”OAuth2 流。

我在 Microsoft GitHub 示例中找到了一个很好的示例，可以为我的场景提供信息

我的问题是，该示例使用 WebApi 应用程序作为服务。这可以访问 HttpContext 对象，使用 Microsft.Identity.Web 程序集中称为“ValidateAppRole”的扩展方法

我的 Azure 函数确实有一个 HttpRequestData 类型的参数。这有一个包含键值对的 headers 属性。其中一个键称为“授权”，其值是 Azure AD 提供的访问令牌。我已经通过 jwt.ms 运行了这个令牌，并且可以确认“角色”集合包含我需要验证的自定义角色。所以我知道所需的信息是存在的；我只是不知道如何以编程方式检查它。

由于 dotnet 隔离的 Azure 函数似乎无法访问 HttpContext 对象。如何进行等同于以下的检查？

HttpContext.ValidateAppRole("CustomRoleName");

【问题讨论】：

我实际上正在开发一个示例函数应用程序来执行此操作。如果可能的话，可能会在几天内发布它。本质上，您需要在自定义中间件中进行身份验证，并将声明主体分配给请求数据上的 Items 集合。然后，您可以对存在的任何声明进行授权，包括您提到的应用权限。没有 HttpContext，因为您的 Function 接收到的调用实际上是来自 Functions 运行时的 GRPC 调用（在单独的进程中运行并处理 HTTP 请求）。
感谢@juunas，这是有道理的。我开始认为我转向 dotnet-isolated 是一个坏主意。除了这个问题，我现在在某些环境中也遇到了 grpc 超时异常（但在其他环境中可以正常工作）。似乎 dotnet-isolated 选项可能过早地普遍可用
@RobBowman - 我自己没有尝试过以下建议---检查您是否可以在所需的类中注入IHttpContextAccessor 以获得HttpContext 您需要通过以下方式注册服务builder.Services.AddHttpContextAccessor()
我认为 @juunas 是对的 - 如果不开发自定义中间件，使用 dotnet-isolated 是不可能的
@RobBowman 如果您有兴趣，这里是示例：github.com/juunas11/IsolatedFunctionsAuthentication

标签： oauth-2.0 azure-active-directory azure-functions microsoft-identity-web

【解决方案1】：

我为此制作了一个示例函数应用程序：https://github.com/juunas11/IsolatedFunctionsAuthentication。

示例包括两个中间件：AuthenticationMiddleware 和 AuthorizationMiddleware。前者验证 JWT 并从中创建一个 ClaimsPrincipal，而后者根据 Function 方法上设置的属性检查 ClaimsPrincipal 上的声明。

您可以在 GitHub 存储库中查看完整代码。身份验证中间件将 ClaimsPrincipal 设置为 FunctionContext：

context.Features.Set(new JwtPrincipalFeature(principal, token));

然后授权中间件可以从同一个上下文对象中获取它：

var principalFeature = context.Features.Get<JwtPrincipalFeature>();

然后代码可以检查特定声明。

Function 方法中也可以使用相同的上下文对象。在示例中，属性与中间件一起使用，因此函数代码本身不必检查授权。

【讨论】：