3.121. <ServerHTTP>

The <ServerHTTP> clause presents a HTTP interface that allows Radiator to be monitored, configured and reconfigured through a standard web browser. The Graphical User Interface (GUI) that it presents is designed to be easy to use and intuitive, and to allow access to the full range of detailed configuration options that are usually access directly by editing the configuration file.
The GUI presented by <ServerHTTP> is a useful alternative to the more traditional editing of the Radiator configuration file. Further it allows access to other useful information about the host that Radiator is running on, the details of the version of Perl installed, and details about the versions and modules of Radiator installed on that host.
The GUI presented by this interface is described in Section 10. Configuring Radiator with GUI.
<ServerHTTP> supports TLS. For more information about TLS parameters, see Section 3.11. TLS configuration.


Any user attempting to connect to <ServerHTTP> is subject to authentication. If authentication does not succeed, then the user is unable to access any web pages. Once logged in, the information the user is permitted to see, and the actions the user is permitted to do are controlled by the user's Privilege Level. The authentication steps are:
  1. Check all the clauses in the AuthBy list, if any, continuing until the AuthByPolicy is met.
  2. If no AuthBy clause succeeds (or if there are no AuthBy clauses), authenticate against the hardwired User name and Password in this clause.
  3. If the hardwired User name is not defined permit authentication as the user ’anonymous’ without a password.
If the last AuthBy returns ACCEPT, the connection is accepted. If the last AuthBy returns IGNORE, or there are no AuthBys, then fall back to the hardwired User name and Password parameters is done.
If you plan to use <AuthBy RADIUS>, you need to configure the AuthBy with the Synchronous parameter. Otherwise <AuthBy RADIUS> returns immediately with IGNORE.
An authentication lasts for the time period given by SessionTimeout, after which the user will be required to log in again.
The users Privilege Level is determined in the following way:
  1. If the successful authentication was from an AuthBy clause, and the user had a Management- Policy-Id reply item, then the Privilege Level is given by the integer in the Management-Policy-Id.
  2. Otherwise the Privilege Level is given by the DefaultPrivilegeLevel parameter.

Privilege Level

The information the user is permitted to see, and the actions the user is permitted to do are controlled by the user's Privilege Level. The Privilege Level is a number from 0 to 15, where 0 is the lowest privilege, (and which does not even permit logging in), and 15 is the highest, which allows all actions.
The Privilege Level is a bitmask obtained by adding together the following numbers:
  • 1: Permission to view basic (non-security-critical) status only.
  • 2: Permission to reset the server
  • 4: Permission to edit and change the running configuration (but not save it)
  • 8: Permission to save changes to the configuration file
For example, to grant privilege to view status and to reset the server, the Privilege Level should be set to 3 (1 + 2). To grant all privileges, the Privilege Level should be set to 15 (1 + 2 + 4 + 8).
Careless configuration of this clause can open security holes in your RADIUS host. In order to limit the possibility of security compromise, It is recommended that you:
  1. Limit the clients that can connect with the Clients parameter.
  2. Make sure the Radiator configuration file is only readable by root.
  3. Consider making Radiator run as a non-privileged user.
  4. Use secure user names and password to authenticate access to this server.
  5. Enable SSL connections only with the UseSSL flag.
  6. Disable this clause when not required.

3.121.1. Port

Port number to listen for connections. Service names or integer port numbers are permitted.

3.121.2. Username

Fallback username to log in as. If there is no Username and no AuthBy clauses, users will not be required to authenticate in order to use the web interface.

3.121.3. Password

Fallback password for Username. Password can be plaintext or any of the encrypted formats such as {crypt}....., {nthash}....., {SHA}...., {SSHA}....., {mysql}...., {msssql}...., {dechpwd}...., {MD5}......, {clear}.... etc.

3.121.4. AuthBy

List of AuthBy clauses to use to handle authentication for new web connections. Requests are processed by each AuthBy in order until AuthByPolicy is satisfied. If there are no AuthBy clauses, the fallback Username and Password will be used.

3.121.5. AuthByPolicy

Specifies whether and how to continue authenticating after each AuthBy.

3.121.6. AuthLog

List of AuthLog clauses which will be used to log authentication of users logging in the Server HTTP interface.

3.121.7. AuditTrail

Optional filename where all editing and configuration changes will be logged. Special characters are supported.

3.121.8. LogMicroseconds

When logging, include microseconds in the time.

3.121.9. SessionTimeout

Maximum time in seconds a session is permitted to continue without logging in again.

3.121.10. LogMaxLines

Maximum number of recent log lines which will be displayed on the Log page.

3.121.11. Trace

Logging trace level. Only messages with the specified or higher priority will be logged.

3.121.12. DefaultPrivilegeLevel

Privilege level to be used if a per-user Management-Policy-Id is not available from a successful authentication from the AuthBy list. The privilege level is a bitmask described above.

3.121.13. PageNotFoundHook

If a page is requested but not found in the set of built-in pages PageNotFoundHook is called to try to handle the request. PageNotFoundHook is passed the requested URI and a reference to the ServerHTTP connection. If it can handle the request, it returns an array of ($httpcode, $content, @httpheaders), else undef.
PageNotFoundHook sub {return (200, "your HTML content");}

3.121.14. Clients

This optional parameter specifies a list of IP addresses that connections will be accepted from. You can specify one or more comma or space separated IP addresses on each Client line. You can specify multiple Client parameters. Only exact matches are supported at present. The default is to accept connections from any and all clients.
If Clients is specified and a client attempts to connect from an IP address that is not named, Radiator will log a WARNING level message then reject and close the connection.
# Only accept connections from some addresses