Difference between revisions of "Subprovider"
Line 12: | Line 12: | ||
* customized standard-template for all mails sent using standalone-client, Outlook addin, Thunderbird addin, Lotus Notes addin | * customized standard-template for all mails sent using standalone-client, Outlook addin, Thunderbird addin, Lotus Notes addin | ||
* shop-pages for premium-membership of single users and group-administrators | * shop-pages for premium-membership of single users and group-administrators | ||
+ | * payment options (PayPal, others) | ||
* blacklist for mail-addresses, domains and sub-domains that are rejected from registering | * blacklist for mail-addresses, domains and sub-domains that are rejected from registering | ||
* Terms and Conditions (German 'AGB') | * Terms and Conditions (German 'AGB') |
Revision as of 09:56, 9 October 2012
Contents
the Subprovider feature
A Subprovider is a way to host multiple regify-provider instances on a single system. In fact, all Subprovider instances of a regify-provider, each visible with different customizing to the customers, is running on the same hardware / virtual host.
individual Subprovider features
The following settings are customizable individual for each Subprovider:
- page-Design by using individual CSS files and images for each Subprovider
- header and footer content
- e-mail templates are completely individual (css-design and text-content)
- customized logo in regify-client (logo in right upper corner)
- customized standard-template for all mails sent using standalone-client, Outlook addin, Thunderbird addin, Lotus Notes addin
- shop-pages for premium-membership of single users and group-administrators
- payment options (PayPal, others)
- blacklist for mail-addresses, domains and sub-domains that are rejected from registering
- Terms and Conditions (German 'AGB')
- customizable authentication form (Subprovider authentication-level can vary)
- used HTTP header meta-information
- individual configuration as community-provider or corporate-provider
- selection of active and inactive portal-options for end-users
- language-specific sentences (limited usage recommended)
The following functions and settings are shared between all Subprovider (not individual):
- maintenance-state
- local paths for downloads, log-files, obligatory attachments and temporary files
- clearing-connection is always shared between all Subproviders
- proxy-settings
- all subproviders share the same currency
- local time-settings (difference to UTC-0)
- premium-time offered as trial period
- number of days a registration, invitation or added mail-address is active/valid
- length of passwords and unlock-codes
- PDF settings
- SMS settings
- some specific authentication-settings
- settings for intrusion detecting system (IDS)
- the definition of administrative accounts is only available to administrators of the main provider
- a Subprovider is able to administrate many functions inside of his domain (user-data, groups etc.), but some functions are still only available to the main providers master-administrators.
prerequisites
In order to manage a Subprovider, the following prerequisites are needed on the hosters side:
- individual IP address for each Subprovider
- individual domain for each Subprovider (A record in DNS entry)
- specific SSL certificate for the desired domain
Sometimes we get asked about the possibility to host multiple subproviders on one IP address only. The short answer is: no. The more detailed answer can get found in the apache documentation.
We also get asked frequently if it is possible to host multiple designs on one single domain (corporate identities). In fact, with no different domains, the portal does not know which design to show. We need this differentiator to determine the correct design. We also do not want the user to add some additional subfolder to its domain (regify.company.com/design1/ or regify.company.com/design2/). Most users are simply typing the main domain. This solution will cause a lot of confusion at the customers.
other important information
- a Subprovider stores his user-data and transaction information in the same database as the main provider. There is no physical separation of the data. Upon this, a later separation into a new provider-instance needs extreme effort.
- Subproviders are sharing their physical resources (CPU power and RAM). A heavy load of a single Subprovider leads into heavy load of all Subprovider-instances.
- upon restricted administration possibilities, it is strongly recommended to manage the complete administration by a employee of the main provider.