Building a webportal which will be rented to customers. Need an Architecture Suggestion

Iam building a web portal which will be rented to customers on a hosted model (SAAS), where they will be using the entire portal features on their own domains with their own branding.

Now I don't want them to get the files of my web-portal, but still be able to use a custom branded portal.

One solution which someone suggested here was to host the branded version on my server and all it via an 开发者_如何学CIframe on the customer's domain. However I didn't like the idea very much.

One second approach which I researched and found was to host the portal on a fresh IP in my server and ask the customer to point his domain to that ip.

The webportal will be sold to lot of customers and they all will have separate User Interfaces and brandings, so this is needed.

Please suggest me what do you feel about my approach or if you guys have a better idea in mind please pour in your suggestions.

---

iFrames are evil.

With that said I would probably go with a subdomain approach. They add a subdomain like webportal.somecompany.com that points to you and have your webserver route them to the correct hosted instance of your application based on subdomain. That way their www.somecompany.com still goes to their website.

---

We're running a SAAS application that supports branding, and we do it by dynamically serving up CSS. If all of your customers have a unique domain name pointed at your server, you could select your CSS files by domain name: If a customer logs in at "http://portal.customer.com/login", you can have his HTML link to the file "/stylesheets/portal.customer.com.css", and so forth. Alternatively, you can create a subdomain for each of your customers, and point them all at your master server, using very similar code to pick the CSS.

This lets you have a single IP address for all customers (and only as many servers as you need to support all your customers behind that IP address), instead of one IP address / server per customer - should cut save on hosting costs!

(NOTE: I'm leaning toward the subdomain approach, the more I think about it. If you're using HTTPS, it would let you use a single "*.yourdomain.com" certificate, rather than trying to mess with separate certificates for each client domain.)

---

You don't need to run different IPs for different customers. HTTP 1.1 supports Host: like so

GET / HTTP/1.1
Host: example.com

This is how most shared hosts work. When a customer sets up their DNS records to point at your server/load balancer, the incoming requests will have your client's hostname in the headers. Whether you set up virtual hosts in say Apache or do it at the application level is up to you.

Please for your own sake don't do iframes. There's a lot of information on the web on architecture for multi tenant applications.

---

I made the experience that in such a scenario your customers will come up with any possible web UI requirement you can imagine. Therefore it is rather difficult to build a web UI framework that can accomodate to all the needs, in fact this would rather be a content management system.

Furthemore, for building the web UI, you may meet any combination of customer in-house development, 3rd party web agency or request to get it developed by yourself.

In such situations I made good experiences with offering the SaaS as actual web services allowing custom developed portals to run on top. With this, anybody can build the actual portal with the clients look and feel. You could offer development and hosting as an option.