Whitelabel: Difference between revisions

From Open-Xchange
(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...")
 
No edit summary
Line 3: Line 3:
=== 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 2 ways of achieving this:
Line 9: Line 9:
* 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.
* 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.


* Use mod_rewrite to let apache do the work for you based on the domain, the user entered in this browser.
* Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in this 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.


Here are 2 screenshots of same docroot but with different themes/login pages.
We recommend that you do it via the mod_rewrite module of Apache. It is less painfull and offers more options for updates.  


[[File:upsell.png|290px|thumb|left|Upsell Layer Mobility]]
[[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
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.
</pre>
 
* Directly display a configurable URL/Online SHOP (systemwide or/and per context configurable) within the upsell Layer window instead of standard OX upsell content.
 
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.
 
The upsell layer has full i18n (EN and DE are included) support integrated and offers following components for advertisement:
 
* Text
* 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).
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.  


=== Configuration ===
For Debian Lenny, please create file:
 
* You have to modify the ox specific vhost of your apache so that the vhost inherits also "mod_rewrite" configurations:


<pre>
<pre>
RewriteEngine On
/etc/apache2/conf.d/rewrite_default_theme.conf
RewriteOptions Inherit
</pre>
</pre>


On Debian lenny you have to add the above 2 lines to the "<VirtualHost>" section of file:
and add following line to it:


<pre>
<pre>
/etc/apache2/sites-available/default
RewriteRule v=\w+/themes/default(.*)$ /themes/%{HTTP_HOST}/$1
</pre>
</pre>

Revision as of 08:55, 21 December 2010

Whitelabeling 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 2 ways of achieving 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.
  • Use mod_rewrite by Apache to do the work for you based on the domain, the user entered in this 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 painfull and offers more options for updates.


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, please create file: 

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

and add following line to it: 

RewriteRule v=\w+/themes/default(.*)$ /themes/%{HTTP_HOST}/$1
Retrieved from "https://wiki.open-xchange.com/wiki/index.php?title=Whitelabel&oldid=6762"