[MVC] LoginController does not account for multi-tenant on SignIn about brockallen.membershipreboot

[brockallen]

I'm still doing lots of little updates here & there (as I'm sure you've noticed) so make sure you have the latest updates.

So related to multi-tenancy, there are two "modes" (so-to-speak): 1) Single-tenant, and 2) Multi-tenant.

If you leave the default setting of SecuritySettings.MultiTenant = false then anytime you use the APIs that don't accept a tenant it uses SecuritySettings.DefaultTenant as the default. If you use the APIs that accept a tenant parameter then that param is ignored and the SecuritySettings.DefaultTenant is used instead.

If you switch to multi-tenant mode (by setting SecuritySettings.MultiTenant = true) then the app must always use the version of the APIs that accept a tenant param. The SecuritySettings.DefaultTenant value is never automatically used. In other words, you have to be explicit and use the version of the APIs that accept the tenant.

So in a sense the two modes really affect the rest of the app -- either the app doesn't know or support multi-tenancy or it does. It seemed necessary to do it this way -- I didn't want to try to accommodate and app that was half one way and half the other.

[brockallen]

And just to clarify this open issue -- I think what you're asking is for a sample that illustrates multi-tenancy, yes? The sample app is only working in single-tenant mode.

[drewid]

Hey Brock - yes regarding multi-tenancy issue. I have been updating the sample app and have it working (so far) in multi-tenancy for registering, confirmation and login. Working my way through.

I have gone ahead and added a session variable in Session_Start for multi-tenancy as I am basing my tenancy off of the subdomain of the main domain. I would prefer some other way to do that, but am not sure if there is a way since it is needed per application instance.

Unfortunately it does not cleanly fit in the App_Start folder and the App_Start call in Global.asax.cs since it is per application instance and not per application.

I have the following. Any suggestions are appreciated. It "does" take into account the multi tenant and default tenant settings you have for the application.

In Global.asax.cs:

   protected void Session_Start()
    {
        TenantConfig tenant = new TenantConfig();
        Session["Tenant"] = tenant.Tenant;
    }

In a file called TenantConfig.cs I have the following. It is in the App_Start folder for now.

//Am including this in the App_Start folder but is really associated with Session_Start
public class TenantConfig
{
private string _tenant;

    public string Tenant
    {
        get
        {
            if (SecuritySettings.Instance.MultiTenant)
            {
                _tenant = GetSubdomain(HttpContext.Current.Request.Url);
            }
            else
            {
                _tenant = SecuritySettings.Instance.DefaultTenant;
            }
            return _tenant;
        }
    }

    private static string GetSubdomain(Uri uri)
    {
        string subdomain = null;
        if (uri.HostNameType == UriHostNameType.Dns)
        {
            string host = uri.Host;
            int lastIndex = host.LastIndexOf('.') - 1;
            if (lastIndex > 0)
            {
                if ((lastIndex = host.LastIndexOf('.', lastIndex)) != -1)
                    subdomain = host.Substring(0, lastIndex);
            }
        }
        return subdomain;
    }
}

In files like RegisterController, I am then referencing the session variable for tenant:

this.userAccountService.CreateAccount(Session["Tenant"].ToString(), model.Username, model.Password, model.Email);

[brockallen]

A tenant claim is issued once the user logs in. So this logic you have for deciding the tenant could be moved into the login action code and then you can stop using session (which is evil: http://brockallen.com/2012/04/07/think-twice-about-using-session-state/). Then anywhere else you can just use ClaimsPrincipal.Current.FindFirst(MembershipRebootConstants.ClaimTypes.Tenant).

[drewid]

Hmm - I do see what you mean... In general I don't like them, but trying to then figure out how to handle any conditional decisions - display/theme/colors/options that would be prior to login. Maybe just a lookup where needed.

In this case since the value is based off of the url - the session should work across any webfarm scenario, etc. since if it doesn't have a value it could always get reset. BUT my case is specifically an edge case I guess.

BTW - definitely agree with the shopping cart scenario.

[brockallen]

I'm going to close this since right now I don't have any plans (or time) to do a multi-tenanacy sample. If you're willing to do one, then feel free to submit/contribute it.