Question

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}' 

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

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 uses an HttpUnauthorizedResult to return a 401 unauthorised status, which I presume causes ASP.NET to redirect to the page defined in web.config.

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?

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 }                 });         }     } } 

Answer 1

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.

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.

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.

Hope that helps!