Portal Home > Knowledgebase > Articles Database > how to implement whitelabeling
how to implement whitelabeling
| Posted by skyy, 12-08-2007, 01:14 AM |
| Hi,
I wonder how to implement the whitelabeling of a web app similar to what Ning did with its social network where ning users can use their own domains. see
http://blog.ning.com/2007/09/what_do...e_white_1.html
The basic use case is that I run a web app at https://www.app.com and http://www.app.com. I want to let other companies to access my web app using their domain (eg: http://app.company1.com, https://app.company1.com) so that the users of company1 don't really know that http://www.app.com actually provides the app.
Notice that I need to support access through SSL.
I prefer not to use a frame to hide the URL.
Thanks.
Sky
|
| Posted by jstanden, 12-08-2007, 02:18 AM |
| Generally, you'd just have the customer set up an "A" record in their DNS that points to one of your IPs.
You can then host that subdomain (app.company1.com) without being authoritative for their entire domain.
You can set up bind and Apache to do wildcard domains, which allow your software to read the incoming hostname and act accordingly without having to set up each site.
|
| Posted by Vinayak_Sharma, 12-08-2007, 02:21 AM |
| What you want to achieve is exactly same like resellerclub.com where we as resellers use domains.myowndomain.com manage.myowndomain.com etc.
I tried it for our helpdesk installed on our main domain and accessible from support.mybrand1.com and support.mybrand2.com.
Now for that we first made a CNAME entry for support at mybrand1.com & mybrand2.com then also made entry in httpd.conf at mymaindomain.com.
Since we did not required customising of interface like header, footer etc. and outgoing mail etc hence it was simple, but if you want to give that feature to your clients, you will need to develop that feature in your App so that it detects which account it is serving to.
|
| Posted by skyy, 12-08-2007, 02:40 AM |
| Thanks for the info.
how about supporting SSL access? Will they need to get a SSL certificate for app.company1.com?
|
| Posted by jstanden, 12-08-2007, 02:45 AM |
| Unless you're self-signing certificates, yeah they'd need to get an SSL certificate to cover their subdomain.
One benefit of doing company1.app.com is you can use a wildcard SSL certificate (*.app.com). That's how we host our applications by default. There are a few customers who want to use their own domain, and we walk them through the process (DNS "A" record for subdomain, SSL). Most don't mind bookmarking a different URL. A URL is a URL, especially if it's not customer-facing.
|
| Posted by skyy, 12-08-2007, 03:13 AM |
| In my case, my customers want to use https://app.company1.com
does that mean I need to store the private key for the ssl certificate for https://app.company1.com on my server?
How can I automate the process of figuring out which domain the request is coming from so that I can display proper customer logos(true whitelabeling) ?
I have load balancer in front of apache which handles static file requests, and a Java Tomcat server which acts as the application server.
|
| Posted by jstanden, 12-08-2007, 03:18 AM |
| Yes, you'd need to host the certificate for this subdomain.
Google "VirtualHost wildcards". From your server-side code (J2EE, etc) you'd check the HTTP host headers for your introspection.
|
| Posted by Xeentech, 12-08-2007, 04:09 AM |
| Each sub-domain would need it's own IP address if it were to be SSL/TLS/HTTPS enabled.
You can't "VirtualHost" when working with SSL/TLS. You need to know what cert to use before the begin SSL negotiation. The only method to date has been to have a dedicated IP address for each SSL enabled site (or port, but that's ugly, and scares none-techy users).
I was once in a similar predicament. My client didn't have the setup to self host an app that was already built, but wanted in on https://sub.his-domain.com.. He wanted to use the same wild card SSL cert he had used for www. helpdesk. kb. etc, and obviously couldn't hand over the wild card cert to a 3rd party, understandably..
We ended up having apache proxy over a vpn. Looked neat on the customer facing side, and was as secure as it gets, but a pain to setup.
|
Add to Favourites 
Print this Article
Also Read
