Question

我遇到了一个可以观察到无限重定向循环的问题。我的项目基于官方MS示例 - active-directory-b2c-dotnet-webapp-and-webapi

“重定向URI”（在Azure门户中定义）是否必须是可公开访问的端点？

如果在我的控制器中我用[Authorize]属性装饰它会怎么样？

所以基本上在这个示例中，Redirect Uri（设置为网站根目录，即localhost:1234/）也是控制器中操作的路由，需要授权。

[Authorize]
public class ControllerA : Controller
{
    [Route("~/")]
    public ActionResult Index()
    {
    }
}

它会导致无限重定向循环吗？

删除路由属性可以解决问题，但与此同时，我觉得这不是问题的真正原因。

我认为与控制器的授权相比，应用程序堆栈中的OWIN授权更高，因此我认为OWIN授权中间件会首先解析Azure广告的响应，而不是强制执行[Authorize]属性政策并提前拒绝。

Answer 1

您当然可以通过这种方式创建无限循环场景，但最终会被Azure AD短路。经过几次循环后，它将停止重定向并显示错误。

redirect_uri不需要是可公开访问的URI，例如，它可以与http://localhost一起使用。它只需要客户可以访问。毕竟，＆＃34;重定向＆＃34;只是服务器发出的HTTP响应。它实际上是由客户端执行的。

通常，您用于授权的控制器（即接收重定向）不应由班级[Authorize]修饰。通常，您只需装饰一些需要登录用户的方法。也就是说，只要用[Authorize]装饰你的回调端点，就可以用[AllowAnonymous]来装饰这个类。

Answer 2

问题和解决方案的核心在以下文档中进行了描述 - System.Web response cookie integration issues。我已经实现了第三个解决方案（重新配置CookieAuthenticationMiddleware直接写入System.Web的cookie集合），它已经解决了这个问题。让我发现cookie是问题的原因是另一个StackOverflow的question，它描述了与我观察到的症状非常相似的症状。

事实上，默认路由[Route("~/")]已映射到需要授权的控制器方法之一，并且它也匹配我在Azure门户中设置的redirect_uri不是罪魁祸首。在我看来，这证明了redirect_uri调用将由OWIN auth中间件直接处理，甚至无法达到控制器的方法。

Azure广告 - 隐藏在授权后面的Uri重定向

2 个答案: