CommuniGate Pro
Version 6.4
 

WebUser Interface Module

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. The WebUser Interface can be used to specify Mailbox Aliases, Remote Poll (External POP and IMAP) accounts, Account Rules, etc.

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 a WebUser port of the CommuniGate Pro server, the Login page is displayed. The WebUser ports are specified in the HTTP User module settings, the default clear-text WebUser port is 8100, the secure one (not configured by default on some platforms) is 9100.

When the Login page is displayed, users can enter their 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. 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 it will retrieve the client.com Login page, too.

If the URL specifies a domain name that is not routed to any CommuniGate Pro 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 would not get this request), but that name is not routed to any of the Server Domains. You should either create a secondary Domain with that name, or route this domain name to one of the existing CommuniGate Pro Domain.

If a URL specifies an IP address instead of a domain name, the WebUser module tries to find a CommuniGate Pro Domain to which the specified address is dedicated. If no 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 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 Certificate 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

Some protocols (such as IMAP and POP) are session-oriented protocols: a client application 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 a session-oriented one: 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 module creates a unique session identifier (session ID) for each virtual session created and makes user browsers 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 connects 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. Users of some large providers access the Internet via the provider's proxy servers, so their accounts should have the address-controlling option disabled.
Alternatively, enter the provider proxy IP addresses as a range into the NAT Server IP Addresses list.
All network IP addresses that belong to the same range in that list are treated as "same".

To avoid "hijacking" of WebUser sessions, the WebUser module can use HTTP "cookies". When the Use Cookies option is enabled, the Server generates some random "cookie" string and sends it to the user browser when a session is initiated. The browser then always sends that string back to the Server when it tries to access any of the session pages. The Server allows the user to access the session data only when the valid "cookie" string is sent.

Note: Some browsers do not support "cookies" or can be configured not to support them. The user should check the browser options before enabling the Use Cookies option.

Usually, users start WebUser sessions by entering their Account names and passwords into the WebUser Interface login page fields. This is a "clear text" login method, and it is secure only when the page is accessed via secure (SSL/TLS) connection (via the https:// URL).

Alternatively, users can retrieve the /login/ URL on your Server. The Server will require an HTTP-level Authentication, and the browser will either present the Authentication dialog box, or it will send the user's Certificate if a secure (SSL/TLS) connection is used.


Automatic Login and Single Sign-on

When designing a set of Web-based services ("portals"), it may be necessary to create a WebUser session without presenting a login page to the user. The following mechanisms can be used.

Automating the Login page
direct the user browser to
http://your.server.domain[:port]/?username=accountName&password=password
HTTP Authentication
direct the user browser to
http://your.server.domain[:port]/login/
If the browser automatically logs into this realm, it will not present the Login dialog to the user.
Certificate Authentication
direct the user browser to
http://your.server.domain[:port]/login/
If the Domain supports Client Certificates, and the proper certificate is installed on the user's computer, the browser automatically logs into this realm, without presenting the Login dialog to the user.
Creating a Session via CLI
use the Network CLI/API to create new WebUser session, then direct the user browser to
http://your.server.domain[:port]/Session/sessionID/Hello.wssp
Automating the Login page with other Session ID
direct the user browser to
http://your.server.domain[:port]/?username=accountName&password=sessionID&SessionIDMethod=yes
This is the same mechanism as the automated Login page mechanism, but the SessionID Authentication method is used instead of the clear-text Authentication method. The sessionID is a the ID of any existing WebUser or XIMSS session with the same accountName Account.

WebUser Interface Settings

To configure the WebUser Interface module, use any Web browser to connect to the CommuniGate Pro WebAdmin Interface, open the Access pages in the Settings realm, and then open the Sessions page.

User Sessions
Log Level: Limit:
Inactivity Time-Out: Session Time Limit:
Compose Limit: Recipients:

 

Safe Link Schemas
Limit
Use this setting to specify the maximum number of concurrent WebUser Interface sessions.
Note: remember that browser (HTTP) connections are not the same as WebUser sessions. It is usually enough to support 100 concurrent HTTP channels to serve 5000 Sessions.
Log
Use this setting to specify what kind of information the WebUser Interface module should put in the Server Log. Usually you should use the Major (message transfer reports) level.
The WebUser Interface module records in the System Log are marked with the WEB tag.
Inactivity Time-Out
Use this setting to specify the maximum time interval between client (browser) connections for a particular WebUser Session. This setting allows to disconnect the users who did not log out correctly, but simply closed their browsers or moved to a different Web site. Do not set this setting to a too small value, otherwise users can get disconnected while they are composing letters.
Session Time Limit
Use this setting to specify the maximum "login" time for a WebUser session. The limit is checked when a browser connects and retrieves a page from the session, so it is useless to set this setting to a value that is smaller than the Inactivity Time-Out setting value.
Compose Limit: Recipients
Use this setting to specify the maximum number of E-mail addresses in messages composed using the WebUser Interface.
Safe Link Schemas
For WebUser and XIMSS Sessions security reasons the server blocks processing of references with unknown types. Use the empty field in this setting to add an URI schema (link prefixes) that is known to be safe for execution in HTML-formatted messages.

Open the HTTP User Module settings, and find the Sub-Protocols panel:

Sub-Protocols
 Access
WebUser:

The Access setting specifies who can create WebUser sessions.


Configuring Spell Checkers

The Server Administrator can specify one or several external spell checker programs. To configure spell checkers, follow the Spelling link on the General Settings page.

The Spelling page appears :

Enabled Language Log Level Program Name and Parameters 
Convert to:
Convert to:
Convert to:
Convert to:

To configure a spell checker, specify the language the program can process, and path to the program file, and the character set the program can handle. The internal data presentation use the UTF-8 character set, so set the UTF-8 value if no conversion is needed.

Use the Log Level setting to specify the type of information the spell checker module should put in the Server Log.

The spell checker module records in the System Log are marked with the SPELLER tag.

Use the Enable check box to enable and disable the spell checker program without removing it from the program list.

To remove a spell checker program, enter an empty string into its Language field and click the Update button.

The spell checker program should provide the same "pipe" interface as the popular Ispell and aspell programs:

  • Text is sent to the program line-by-line with the first symbol of the line being a space symbol;
  • For each input line, the program returns zero, one, or several non-empty response lines followed by an empty line.
  • Only the response lines that start with the ampersand (&) or hash (#) symbols are processed.
  • The hash-line has the following format:
    # original offset
    where original is a misspelled word, and offset is the position of that word in the input text line.
  • The ampersand-line has the following format:
    & original count offset:suggestion1, suggestion2, ...
    where original is a misspelled word, and offset is the position of that word in the input text line, count is the number of suggestions.

Note: the path, name and parameters of a spell checker program must be registered in the Child Processes Manifesto.


WebUser Interface to Mailing Lists

The WebUser module presents a link to the Mailing Lists page on the 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 archive. Since Mailing Lists messages are archived in Mailboxes, the Mailing List WebUser interface is similar to the Mailbox Browsing interface.

The Mailing List WebUser 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.


CommuniGate Pro Guide. Copyright © 2020-2023, AO StalkerSoft