CommuniGate Pro Web User Interface |
||||||||||||||||||||||||||||||||||||||||||
|
The WebUser module checks for the domain name specified in the URL and presents the Login page for the addressed domain. If the CommuniGate Pro server provider.com has a secondary domain client.com, then the <http://provider.com:port> URL will display the provider.com Login page in a user browser, and the <http://client.com:port> URL will display the client.com Login page, even if the client.com has no dedicated IP address.
When the WebUser module retrieves the domain name from a URL, it runs it through the Router domain-level records. So, if the Router Table has a record:
www.client.com = client.com
If the URL specifies a domain that is not among the main and secondary server domains, an error page is displayed. This usually indicates an error in your Server setup: the specified domain name has a DNS A-record that points to your server (otherwise the server will not get this request), but that name is not routed to any of the secondary domains on your server. You should either create a secondary domain with that name, or route this domain to one of the existing CommuniGate Pro domains.
If a URL specifies an IP address instead of a domain name, the WebUser module tries to find a secondary domain to which the specified address is dedicated. If no secondary domain is found, the main domain Login page is displayed.
Users can open any account in any domain from any Login page, if they specify the complete account name: if the Login page of the main Server domain is displayed (<http://provider.com:port>) and the username@client.com name is entered in the username field, the account username will be opened in the client.com domain (if the correct password is provided).
If a domain has some mailing lists, its Login page contain a link to the Mailing List archive pages.
If the Domain has the Auto-Signup option enabled, a link to the Auto Sign-up page is displayed on the domain Login page.
If the Domain has a custom Security Certificate, a Ceftificate link is displayed. If a user clicks that link, the Domain Certificate can be installed as a trusted Certificate in the user browser.
To provide the session-type functionality, the WebUser module implements a so-called application server: when a user is authenticated via the "login page", a virtual session is created. The virtual session is an internal server data structure keeping the information about the user, open mailboxes, and other session-related data, but it is not linked to any particular network connection. When the user is working with an account using a browser, the WebUser module routes browser requests to one of the already opened virtual sessions.
In order to route requests properly, the WebUser creates a unique session identifier (session ID) for each virtual session created and makes user browsers to include the session ID into every request they send.
To avoid "hijacking" of WebUser sessions, the WebUser module remembers the network (IP) address from which the login request was received, and routes to the session only the requests received from the same IP address.
Note: Sometimes, when a user works via a proxy server, the user requests may come to the Server from different IP addresses (if the proxy server uses several network addresses). In this case, the user should disable the address-controlling option on the WebUser Interface Settings page. Usually, users of large provders (such as AOL, WebTV) access the Internet via the provider's proxy servers, so their accounts should have the address-controlling option disabled.
The Mailing Lists page displays all mailing lists created in the domain that have the allow anybody to browse option enabled. Each name is a link that can be used to open a page listing messages in the mailing list. Since mailing lists are archived in mailboxes, the mailing list WebUser interface is similar to the Mailbox Browsing interface.
The mailing list Web User Interface does not require any authentication, so no virtual session is created for list users, and each browser request is processed independently.
When a new account is created, its options and settings are taken from the domain Account Template.
The WebUser directory contains the basic HTML files and all the graphic files. Its Account subdirectory contains all HTML files used to provide WebUser Interface to user accounts. The List subdirectory of the WebUser directory contains the HTML files used to provide WebUser interface to mailing lists. The WebUser directories inside the domain directories should have the same layout.
The Strings.data file stored in the WebUser directory contains a dictionary with all customizable HTML elements used to compose WebUser Interface HTML pages.
When the WebUser module needs to retrieve any file, it looks into the WebUser directory inside the domain directory first. If the requested file is not found there (those WebUser directories are initially empty), the module retrieves the file from the WebUser directory inside the application directory.
To customize the WebUser Interface, you should place your version of a WebUser Interface file into the proper location in the WebUser directory inside a domain directory. Your version of the file will be used for all accounts and lists in that domain.
Note: avoid modifying the original files in the WebUser directory inside the CommuniGate Pro application directory: when you update the software, all files in the application directory are rewritten, while files in the base directory (including the files inside the domain WebUser directories) are left intact.
The Domain Administrator can place HTML and other files into the WebUser directory (publish them):
The WebUser Interface Editor is the preferred method. Click the WebUser link on the top of any Domain Administration page, and the the list of all available WebUser files will appear. The list contains files found in the application directory WebUser subdirectory and the custom files already stored in the domain WebUser directory:
If the file does not exist in the domain WebUser directory, the file from the application
directory WebUser subdirectory is shown, and the default marker is displayed.
If the file exists in the domain WebUser directory, that file is shown and a check box is
displayed in the Marker field.
The subdirectories of the WebUser directory (Account, List) are listed, too and you can open them
by following the subdirectory link.
To modify some element of the WebUser Interface:
If the WebUser directory/subdirectory did not contain a custom copy of the uploaded file, you will see the default file marker changing to a checkbox. If a custom version of that file already existed in the WebUser directory/subdirectory, the old version is replaced with the uploaded one.
To remove a custom version of a WebUser Interface file, select the checkbox on the left of that file name and click the Delete Marked button. If the file with that name exists in the application directory WebUser subdirectory, the file name does not disappear from the WebUser Interface Editor page, but the name gets the default marker indicating that the default (original) version of the file will be used again.
To modify WebUser Interface files using an HTML editor that supports the PUT HTTP method (Netscape® Composer or similar product):
To serve heavily loaded sites, the WebUser module uses an internal cache for the WebUser Interface files. When you upload the custom versions of the WebUser Interface files using the HTML Upload File form method or HTTP PUT method, the CommuniGate Pro server automatically clears the internal domain cache (on all servers in the cluster if you employ a Dynamic Cluster), so the new file version becomes effective immediately.
If you modified the WebUser Interface files bypassing the CommuniGate Pro server (i.e. you have moddified those files "in place" or uploaded them and moved into the WebUser directory using the Server OS commands), you should click the Flush Cache button on the Domain Settings page, or you can completely switch WebCaching off for that domain. See the Domains section for the details.
If you choose to modify the original files in the application directory, you may want to restart the CommuniGate Pro Server with the --NoWebCache option to completely disable the WebUser Interface caching. When you upgrade to the new version of the CommuniGate Pro Server, the application directory is completely replaced with the new files. If you choose to modify files in the application WebUser directory, save them to a different location before you update your CommuniGate Pro Server software.
Note: The Strings.data file is always cached. You need to use the Flush Cache button to reload the Strings.data file from the domain WebUser directory, and you need to restart the Server after you have updated the Strings.data in the application directory.
The HTML files used in the WebUser module are, in fact, the "macro files" - these text files contain macro-symbols (two-symbol combinations starting with the caret symbol ^), that are substituted with the actual account data. You should use the same macro-symbols in your versions of the WebUser pages, but you can remove some of them.
For the session-based WebUser Account Interface the Session ID (see above) is a required parameter. The WebUser module substitutes the macro symbol ^# with the current Session ID, and it expects to get the Session ID from the SID URL parameter. Check that your versions of the WebUser Account Interface pages ensure correct passing of a Session ID within a session.
Sometimes you want to add non-HTML and non-Image files to your customized WebUser Interface design (css style sheets files, pdf documents, etc.). You should place these files into the upper level of the domain WebUser folder (not inside the Account and List subfolders). The CommuniGate Pro WebUser Interface may not serve those files, though - it can retrieve only files with .html, .gif, and .jpg extensions specified in the top-level URLs (http://yourserver:8100/filename.extension). This is done to support Personal WebSites without a special prefix, when the string abc.xyz is interpreted as the reference to the abc.xyz user WebSite, not as a reference to the abc.xyz file. To overcome this problem, refer to those files as http://yourserver:8100/Files/filename.extension. The server will remove the Files "realm prefix" and will treat the rest of the URL as the file name.