如何重定向到 ASP.NET MVC 中的动态登录 URL [英] How to redirect to a dynamic login URL in ASP.NET MVC

问题描述

我正在创建一个多租户网站，用于为客户托管页面.URL 的第一段将是一个标识客户端的字符串，在 Global.asax 中使用以下 URL 路由方案定义:

I'm creating a multi-tenancy web site which hosts pages for clients. The first segment of the URL will be a string which identifies the client, defined in Global.asax using the following URL routing scheme:

"{client}/{controller}/{action}/{id}"

这很好用，使用诸如/foo/Home/Index 之类的 URL.

This works fine, with URLs such as /foo/Home/Index.

但是，当使用 [Authorize] 属性时，我想重定向到也使用相同映射方案的登录页面.因此，如果客户端是 foo，则登录页面将是/foo/Account/Login 而不是 web.config 中定义的固定/Account/Login 重定向.

However, when using the [Authorize] attribute, I want to redirect to a login page which also uses the same mapping scheme. So if the client is foo, the login page would be /foo/Account/Login instead of the fixed /Account/Login redirect defined in web.config.

MVC 使用 HttpUnauthorizedResult 返回 401 未授权状态，我认为这会导致 ASP.NET 重定向到 web.config 中定义的页面.

MVC uses an HttpUnauthorizedResult to return a 401 unauthorised status, which I presume causes ASP.NET to redirect to the page defined in web.config.

那么有谁知道如何覆盖 ASP.NET 登录重定向行为?或者通过创建自定义授权属性在 MVC 中重定向会更好吗?

So does anyone know either how to override the ASP.NET login redirect behaviour? Or would it be better to redirect in MVC by creating a custom authorization attribute?

编辑 - 答案:在深入研究 .Net 源代码后，我认为自定义身份验证属性是最佳解决方案:

EDIT - Answer: after some digging into the .Net source, I decided that a custom authentication attribute is the best solution:

public class ClientAuthorizeAttribute: AuthorizeAttribute
{
    public override void OnAuthorization( AuthorizationContext filterContext )
    {
        base.OnAuthorization( filterContext );

        if (filterContext.Cancel && filterContext.Result is HttpUnauthorizedResult )
        {
            filterContext.Result = new RedirectToRouteResult(
                new RouteValueDictionary
                {
                    { "client", filterContext.RouteData.Values[ "client" ] },
                    { "controller", "Account" },
                    { "action", "Login" },
                    { "ReturnUrl", filterContext.HttpContext.Request.RawUrl }
                });
        }
    }
}

推荐答案

我认为主要问题是，如果您要搭载内置的 ASP.NET FormsAuthentication 类(并且没有充分的理由不应该t)，在一天结束时会调用 FormsAuthentication.RedirectToLoginPage()，它会查看一个配置的 URL.永远只有一个登录 URL，而且他们就是这样设计的.

I think the main issue is that if you're going to piggyback on the built-in ASP.NET FormsAuthentication class (and there's no good reason you shouldn't), something at the end of the day is going to call FormsAuthentication.RedirectToLoginPage() which is going to look at the one configured URL. There's only one login URL, ever, and that's just how they designed it.

我对这个问题的尝试(可能是 Rube Goldberg 的实现)是让它重定向到所有客户端共享的根目录下的单个登录页面，比如/account/login.这个登录页面实际上不会显示任何内容；它检查 ReturnUrl 参数或我在会话中获得的某个值，或一个识别客户端的 cookie，并使用它来立即 302 重定向到特定的/client/account/login 页面.这是一个额外的重定向，但可能不会引起注意，它允许您使用内置的重定向机制.

My stab at the problem (possibly a Rube Goldberg implementation) would be to let it redirect to a single login page at the root shared by all clients, say /account/login. This login page wouldn't actually display anything; it inspects either the ReturnUrl parameter or some value I've got in the session or a cookie that identifies the client and uses that to issue an immediate 302 redirect to the specific /client/account/login page. It's an extra redirect, but likely not noticeable and it lets you use the built in redirection mechanisms.

另一种选择是在描述时创建自己的自定义属性，并避免在 FormsAuthentication 类上调用 RedirectToLoginPage() 方法的任何内容，因为您将用您自己的重定向逻辑替换它.(您可能会创建自己的类似类.)因为它是一个静态类，所以我不知道您可以通过什么机制注入自己的替代接口并让它与现有的 [Authorize] 属性神奇地一起工作，它打击，但人们以前也做过类似的事情.

The other option is to create your own custom attribute as you describe and avoid anything that calls the RedirectToLoginPage() method on the FormsAuthentication class, since you'll be replacing it with your own redirection logic. (You might create your own class that is similar.) Since it's a static class, I'm not aware of any mechanism by which you could just inject your own alternative interface and have it magically work with the existing [Authorize] attribute, which blows, but people have done similar things before.

希望有帮助！

这篇关于如何重定向到 ASP.NET MVC 中的动态登录 URL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！