![]() |
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).
All domain Login pages contain links to the Mailing List archive pages, to the Auto Sign-up page, and to other domain-related pages.
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. 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.
The mailbox names are links to the WebUser pages displaying the mailbox contents.
You can open the Settings page and specify which mailbox should be displayed in the Mailboxes page:
For each message in the mailbox, several message header fields are displayed. The messages are sorted by the highlighted field. The field name (link) can be used to highlight a different field and to change the sorting order.
A message can be opened using a link in the first and/or highlighted columns.
The following buttons appear if the WebUser Interface Delete Mode is set to Mark
If the the WebUser Interface Delete Mode is set to Via Trash or Immediately, the following button appears:
You can open the Settings page and specify how mailboxes should be displayed:
The WebUser Interface Settings page also allows you to specify the Delete Mode:
A mailbox message is displayed as an HTML page, containing the important fields of the message header, the decoded message body, and the controls. Text, HTML, and graphics MIME parts are displayed, other parts (attachments) are shown as icon links that allow a user to download these parts.
The multipart - messages are displayed according to the MIME multipart rules, the nested messages are displayed, too.
The message header (and message headers of all embedded messages) have icon-links that allow a user to view the complete header information, and to view the undecoded message body.
The following controls are placed on message pages:
You can open the Settings page and specify how messages should be displayed:
The Composer page can be displayed either directly, or as a result of a Reply or Forward command.
The Composer page allows a user to specify the message subject, to enter the recipient address(es), to specify if the DSN (Delivery Status Notification) is required, to enter the message text, and to attach files to a message.
When forwarding a message, the original message is displayed below the message text area. The forwarded message are composed in the multipart MIME format.
You can open the Settings page and tune the Composer options:
^T | the date and time when the original message was sent |
^F | the From address of the original message |
^N | the EOL (end of line) character(s) |
You can open the Address Book panel in the Composer page, by clicking the Address Book button:
When you open any message, you can use the Take Address button to add the message author (From:) address to your Address Book.
The WebUser uses the ACAP-compatible format for the Address Book dataset, so the addresses entered via the WebUser interface can be used in any ACAP-savvy mailer, and the addresses added using such a mailer would appear in the WebUser Address Book panel.
The Settings page contains the options that customize Accesses to Mailboxes, Mailbox Browsing, Message Browsing, and Message Composing. Besides, it contains some generic settings:
The WebUser Interface Settings page allows you to modify the account password:
To update your password, enter your current password, then enter your new password twice, and click the Modify button.
The WebUser Interface Account Settings page contains a link to the account Subscription page. A user can modify the subscription by entering new mailbox names into an empty field on that page. To remove a mailbox name from the account subscription, a user should empty the name field.
The WebUser Interface Account Settings page contains a link to the account Public Info page:
Users can update their Publicly Available Information by modifying the data in the value fields. To create a new attribute, a user should enter the attribute name into the empty attribute name field in the line table row. Settings any value field to the empty string deletes that attribute.
The editor always shows a set of well-known (though still not standardized) attributes, but it does not store them if their values are empty.
A user can turn the Auto-Reply option and can modify the Auto-Reply message text even if the Can Modify Account Rules option is not enabled for that user account.
See the Automated Mail Processing Rules section to learn how to specify the Rules.
If the Can Modify RPOP Accounts account option is not enabled, then the list of RPOP Accounts can be viewed, but they cannot be modified by the account user.
See the RPOP Module section to learn how to specify the Remote POP Accounts to poll.
To grant access rights to a user, enter the user name into the Identifier field, select the desired access rights, and click the Update button. To grant an access right to everybody, use the word anyone. To remove certain rights from a particular user, "grant" those rights to the identifier -username.
You can open the Subscription page using the link on the Setting page:
Type a mailbox name into an empty field and click the Update button to add a mailbox to the subscription list.
To specify a Foreign mailbox, type the tilda sign (~), the user name, the slash sign (/) and then the mailbox name. Make sure that user has already granted you the Select access right for that mailbox.
You may want to access a mailbox without including it into your subscription list. Type the mailbox name in the Open Mailbox panel and click the Go button:
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.