views:

372

answers:

2

This question is different from the others because all of the questions I've seen so far are talking about the database. I understand the database side of multitenacy, but I'm not 100% sure on the way to do the front end.

I'm working on the design for a product that will basically be a hosted service for customers. As far as the multitenacy goes, you can think of a hosted FogBugz account. The customer signs up, they get their own subdomain, and then they go to customersubdomain.thenormalurl.com and login to their little portion of the application.

When the customer signs up we will need to setup a DNS record for the sub domain, but from the application side of it, how do we "scope" the application to that customer? Is it just supposed to look at the url that the request was made to or is there some other way? That seems overly simple to me, but maybe I'm just trying to complicate something that should be simple.

How is this normally done in the ASP.Net world?

+3  A: 

Luke Sampson has some techniques and sample code for multi-tenant applications using sub-domains under ASP.NET MVC here:

http://blog.lukesampson.com/2009/07/subdomains-for-single-application-with.html

Robert Harvey
+2  A: 

Yeah, just look at the subdomain. If your users log in, then you can ignore the subdomain and figure out who they are by their login credentials. After you figure out who they are, then it's just a matter of getting the right data and not showing the wrong data. And that's where all those DB questions come in. You do that 'scoping' by either using separate DBs or by marking all your records with keys to the customer. So your app has to implement that.

Scott Saunders
So it's really just that simple? On the login page just check the subdomain and the credentials, and then just use the authenticated user from then on? That's it? I guess that makes sense, I was just sure there was something I wasn't thinking about
Max Schmeling
It's really that simple from this end. The big decisions are about how to keep the data separate. All your queries need to do the right thing - whatever that is according to how you structure the data.
Scott Saunders