Difference between revisions of "Subprovider"

From regify WIKI
Jump to navigation Jump to search
Line 45: Line 45:
  
 
== other important information ==
 
== other important information ==
# A Subprovider stores his userdata and transaction information <u>in the same database as the main provider</u>. There is <u>no physical separation</u> of the data. Upon this, a later seperation into a new provider-instance needs extreme effort.
+
# a Subprovider stores his userdata and transaction information <u>in the same database as the main provider</u>. There is <u>no physical separation</u> of the data. Upon this, a later seperation into a new provider-instance needs extreme effort.
 
# Subproviders are sharing their physical ressources (CPU power and RAM). A heavy load of a single Subprovider leads into heavy load of all Subprovider-instances.
 
# Subproviders are sharing their physical ressources (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.
+
# upon restricted administration possibilities, it is strongly recommended to manage the complete administration by a employee of the main provider.
  
 
== when to choose Subprovider ==
 
== when to choose Subprovider ==

Revision as of 14:35, 18 March 2011

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.

Subprovider Scheme.jpg

shared 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
  • blacklist for mailaddresses, domains and sub-domains that are rejected from registering
  • Terms And Conditions (german 'AGB')
  • customizable authentication form (subproviders authentication-level may vary)
  • used http header meta-information
  • individual configuration as community-provider or corporate-provider
  • selection of active and inactive portal-options for end-users

non-shared features

The following functions and settings are shared between all Subprovider (not individual):

  • language-specific sentences
  • maintenance-state
  • local pathes for downloads, logfiles, obligatory attachments and temporary files
  • clearing-connection is allways shared between all Subproviders
  • proxy-settings
  • local time-settings (difference to UTC-0)
  • premium-time offered as trial period
  • number of days a registration, invitation or added mailaddress is active/valid
  • length of passwords and unlock-codes
  • PDF settings
  • emergency SMS settings (they all will go to the administrator of the main provider)
  • 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 (userdata, 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

other important information

  1. a Subprovider stores his userdata and transaction information in the same database as the main provider. There is no physical separation of the data. Upon this, a later seperation into a new provider-instance needs extreme effort.
  2. Subproviders are sharing their physical ressources (CPU power and RAM). A heavy load of a single Subprovider leads into heavy load of all Subprovider-instances.
  3. upon restricted administration possibilities, it is strongly recommended to manage the complete administration by a employee of the main provider.

when to choose Subprovider

A subprovider is an option for customers that are planning to provider the regify service to a limited number of accounts (eg for a maximum of 1000 users). Furthermore, a Subprovider makes only sense if the number of accounts exceeds the limit of a few hundred accounts.

If you plan to grow the number of user-accounts up to a few thousands, you definitely should host your own regify-provider.

If you plan to process very high secure data, it may be a good idea to protect your users by hosting your own provider.