Difference between revisions of "Whitelabel"

(Created page with "= Whitelabeling the Open-Xchange Gui = === Introduction === Within many environments, it is needed that the OX GUI, especially the LOGIN page is branded to the customers/resell...")
 
m
 
(7 intermediate revisions by one other user not shown)
Line 1: Line 1:
= Whitelabeling the Open-Xchange Gui =
+
= White-labeling the Open-Xchange Gui =
  
 
=== Introduction ===
 
=== Introduction ===
  
Within many environments, it is needed that the OX GUI, especially the LOGIN page is branded to the customers/resellers corporate identity or domain.  
+
In many hosting environments, it is needed that the OX GUI, especially the LOGIN page is branded/whitelabeled to the reseller/customer corporate identity or domain.  
  
There are 2 ways of achieving this:
+
There are basically 3 ways to achieve this:
  
* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.
+
* Provision the "theme" into each new user via OX APIs like SOAP, RMI or CLT. But then you still need to create a new vhost for each of your resellers and you need to copy the whole GUI. This way, you have to modifiy the provisioning and need to copy the OX GUI after each update.
  
* Use mod_rewrite to let apache do the work for you based on the domain, the user entered in this browser.
+
* Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI including all themes to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.
  
Here are 2 screenshots of same docroot but with different themes/login pages.
+
* Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in his browser. With this way, you only have to change the default theme and the GUI will be served from only one directory. This way, you have nearly nothing to do after you have update the OX GUI.
  
[[File:upsell.png|290px|thumb|left|Upsell Layer Mobility]]
+
We recommend that you do it via the mod_rewrite module of Apache. It is less painful and offers more options for you.
[[File:Upsell_infostore.png|290px|thumb|left|Upsell Layer Infostore]]
 
[[File:upsell_calendar.png|290px|thumb|left|Upsell Layer Calendar]]
 
  
 +
=== Configuration ===
  
We have implemented 3 different types how to process the upsell an user is requesting in the hosters backend:
+
* You have to modify the OX specific vhost of your apache so that the vhost inherits also "mod_rewrite" configurations:
  
* Show the Upsell Layer window and trigger the upgrade via a generated email to an email address after user clicked "buy" or "trial".
+
<pre>
 +
RewriteEngine On
 +
RewriteOptions Inherit
 +
</pre>
  
In this email there is the information which user from which contaxt wants to upgrade to which package. After receiving the email the hoster's sales team can put the customer into billing.
+
On Debian Lenny you have to add the above 2 lines to the "<VirtualHost>" section of file:
  
* Show the Upsell Layer window and open a configurable URL including all needed parameters after the user clicked "buy" or "trial.
+
<pre>
 +
/etc/apache2/sites-available/default
 +
</pre>
  
This is the perfect automated way if the hoster wants to have a full automated upsell which he can easily integrate into his existing provisioning & billing system.
 
  
* Directly display a configurable URL/Online SHOP (systemwide or/and per context configurable) within the upsell Layer window instead of standard OX upsell content.
+
Now you have to create a new config file to the main Apache configuration which will rewrite all requests from "/themes/default" to "/themes/<FQDN>", where "<FQDN>" will be replaced by the domain the user entered in his browser to access the Open-Xchange GUI.  
  
This is the perfect automated way for all hosters which have an online shop in place and wants to use it for the upsell, too.
+
For Debian Lenny, create file:
 
  
The upsell layer has full i18n (EN and DE are included) support integrated and offers following components for advertisement:
+
<pre>
 +
/etc/apache2/conf.d/rewrite_default_theme.conf
 +
</pre>
  
* Text
+
and add the following line to it:
* Video
 
* Screenshots
 
 
 
to promote a certain feature for Open-Xchange.
 
 
 
The important part of the upsell layer is the ability to pass all needed parameters from users session like username,id,cid etc. + the feature he wants to buy, to a third party online shop system or send these parameters via email in machine readable (configurable) format to a dedicated mailsystem which can process it via procmail or similar to trigger the upgrade process via the Open-Xchange API´s (SOAP,RMI,CLT).
 
 
 
=== Configuration ===
 
 
 
* You have to modify the ox specific vhost of your apache so that the vhost inherits also "mod_rewrite" configurations:
 
  
 
<pre>
 
<pre>
RewriteEngine On
+
RewriteRule v=\w+/themes/default(.*)$ /themes/%{HTTP_HOST}/$1
RewriteOptions Inherit
 
 
</pre>
 
</pre>
  
On Debian lenny you have to add the above 2 lines to the "<VirtualHost>" section of file:
+
Assuming that your users access the OX GUI via "http://webmail.brand.com", you have to copy the "default" theme to "webmail.brand.com" and then modify it to suit your needs.
  
 
<pre>
 
<pre>
/etc/apache2/sites-available/default
+
cp -r /var/www/ox6/themes/default /var/www/ox6/themes/webmail.brand.com
 
</pre>
 
</pre>
 +
 +
To make it even more useful, you could now try to modify the mod_rewrite configuration to only rewrite some URls the UI is requesting, like the LOGIN logo or the main logo , which is used in the GUI after logging in etc. This way, you only need to modify 3-4 files and the main part of the GUI will be loaded by the "default" theme.

Latest revision as of 09:18, 21 December 2010

White-labeling the Open-Xchange Gui

Introduction

In many hosting environments, it is needed that the OX GUI, especially the LOGIN page is branded/whitelabeled to the reseller/customer corporate identity or domain.

There are basically 3 ways to achieve this:

  • Provision the "theme" into each new user via OX APIs like SOAP, RMI or CLT. But then you still need to create a new vhost for each of your resellers and you need to copy the whole GUI. This way, you have to modifiy the provisioning and need to copy the OX GUI after each update.
  • Create a vhost/domain for every customer/reseller like "reseller.domain.com" and copy the whole OX GUI including all themes to that new vhost. After that is done, you have to modify the "default" theme of the OX GUI. The drawback of that solution is, that you now have multiple copies of the OX GUI, which is very bad regarding seamless updates/upgrades. After each update, you have to copy the GUI again for every domain/reseller you have created a vhost for.
  • Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in his browser. With this way, you only have to change the default theme and the GUI will be served from only one directory. This way, you have nearly nothing to do after you have update the OX GUI.

We recommend that you do it via the mod_rewrite module of Apache. It is less painful and offers more options for you.

Configuration

  • You have to modify the OX specific vhost of your apache so that the vhost inherits also "mod_rewrite" configurations:
RewriteEngine On
RewriteOptions Inherit

On Debian Lenny you have to add the above 2 lines to the "<VirtualHost>" section of file:

/etc/apache2/sites-available/default


Now you have to create a new config file to the main Apache configuration which will rewrite all requests from "/themes/default" to "/themes/<FQDN>", where "<FQDN>" will be replaced by the domain the user entered in his browser to access the Open-Xchange GUI.

For Debian Lenny, create file:

/etc/apache2/conf.d/rewrite_default_theme.conf

and add the following line to it:

RewriteRule v=\w+/themes/default(.*)$ /themes/%{HTTP_HOST}/$1

Assuming that your users access the OX GUI via "http://webmail.brand.com", you have to copy the "default" theme to "webmail.brand.com" and then modify it to suit your needs.

cp -r /var/www/ox6/themes/default /var/www/ox6/themes/webmail.brand.com

To make it even more useful, you could now try to modify the mod_rewrite configuration to only rewrite some URls the UI is requesting, like the LOGIN logo or the main logo , which is used in the GUI after logging in etc. This way, you only need to modify 3-4 files and the main part of the GUI will be loaded by the "default" theme.