CommuniGate Pro Web User Interface

Intro
Installation
SysAdmin
Objects
Transfer
Access 
Sharing 
POP 
IMAP 
Web User
LDAP 
ACAP 
PWD 
Directory
Data Files
Clusters
Miscellaneous
WebMail
Licensing
HowTo
The CommuniGate Pro server provides Web (HTTP/HTML) access to user accounts. The WebUser component works via the HTTP module and allows users to read and compose messages and to perform account and mailbox management tasks using any Web browser.

Even if a user prefers a regular POP or IMAP mail client, the WebUser interface can be used to access the features unavailable in some mailers. For example, the WebUser interface can be used to specify Subscriptions and Access Control Lists for account mailboxes - the features many IMAP clients do not support yet.

This sections describes the WebUser Interface from the administrator point of view. See the WebMail section for more detailed user-level information.

WebUser Interface to Multiple Domains

When a user points a browser to the CommuniGate Pro server (to the WebUser port specified in the HTTP module settings), the Login page is displayed. The user can enter his or her name and password and start a WebUser Session.

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
the <http://www.client.com:port> URL will be processed as the <http://client.com:port> URL and will display the client.com Login page, too.

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.


Account Access and WebUser Sessions

IMAP and POP are session-oriented protocols: a client mailer establishes a connection with a server, provides the data needed to authenticate the user, processes the data (mailboxes, settings, etc.) in the user account, and then closes the connection. The HTTP protocol is not session-oriented: a Web browser establishes a connection, sends one or several page requests, receives the requested data, and closes the connection.

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.


WebUser Interface to Mailing Lists

The WebUser module presents a link to the Mailing Lists page on a domain Login Page.

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.


Auto Sign-up

If a domain has the Auto-Signup option enabled, the WebUser Interface Login page contains a link to the Auto-Signup page. This page allows a new user to enter a user name, a password, the "real-life" name, and to create a new account.

When a new account is created, its options and settings are taken from the domain Account Template.


WebUser Interface Customization

The Web User Interface files are stored in the WebUser directory inside the application directory. Also, inside each domain directory, an empty WebUser directory is created.

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:

MarkerFile NameSizeModified
Account/
defaultAnsweredLetter.gif89027-Feb-99
defaultAttachedFile.gif114727-Feb-99
DeletedLetter.gif89627-Feb-99
defaultDenied.html30626-Mar-99
Directory.html119506-Aug-99
defaultDisconnected.html30627-Feb-99
....
Lists/
....
defaultUserSiteIndex.html101924-Aug-99
Totals:3029K 

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.


CommuniGate® Pro Guide. Copyright © 1998-2000, Stalker Software, Inc.