Web/Options (I) page

The 4D Web Server has a cache that allows you to load static pages, GIF images, JPEG images (<128 kb) and style sheets (.css files) in memory, as they are requested.
Using the cache allows you to significantly increase the Web server’s performance when sending static pages.

The cache is shared between all the Web processes. You can set the size of the cache in the Preferences. By default, the cache of the static pages is not enabled. To activate it, simply check the Use the 4D Web cache option.

You can modify the size of the cache in the Pages Cache Size area. The value you set depends on the number and size of your Web site’s static pages, as well as the resources that the host machines has at its disposal.

Note: While using your Web database, you can check the performance of the cache by using the routine WEB GET STATISTICS. If, for example, you notice that the cache’s rate of use is close to 100%, you may want to consider increasing the size that has been allocated to it.
The /4DSTATS and /4DHTMLSTATS URLs allow you to also obtain information about the cache’s state. Please refer to the Information about the Web Site section.

Once the cache has been enabled, the 4D Web server looks for the page requested by the browser first in the cache. If it finds the page, it sends it immediately. If not, 4D loads the page from disk and places it in the cache.
When the cache is full and additional space is required, 4D “unloads” the oldest pages first, among the least demanded ones.

At any moment, you can clear the cache of the pages and images that it contains (if, for example, you have modified a static page and you want to reload it in the cache).
To do so, you just have to click on the Clear Cache button. The cache is then immediately cleared.

Allows you to set the maximum timeout before closing for inactive Web processes on the server.

This option indicates the strictly high limit of Maximum Concurrent Web Processes of any type (standard Web processes or belonging to the“pool of processes”) that can be simultaneously open on the server. This parameter allows prevention of 4D Server saturation as the result of massive number of requests.

By default, this value is 32000. You can set the number anywhere between 10 and 32000.

When the maximum number of concurrent Web processes (minus one) is reached, 4D no longer creates new processes and sends the following message “Server unavailable” (status HTTP 503 – Service Unavailable) for each new request.

Note: You can also set the maximum number of Web processes using the WEB SET OPTION command.

In theory, the maximum number of Web processes is the result of the following formula: Available memory/Web process stack size.
Another solution is to visualize the information on Web processes displayed in the Runtime Explorer: the current number of Web processes and the maximum number reached since the Web server boot are indicated.

Enables or disables the internal mechanism for automatic handling of user sessions by the 4D HTTP server. This mechanism is described in the Web Sessions Management section.

By default, this mechanism is enabled in databases created with 4D v13 and later versions. However, for compatibility reasons, it is disabled in databases converted from previous versions of 4D. You must enable it explicitly in order to benefit from this functionality.

When this option is checked, the "Reuse Temporary Contexts" option is automatically checked (and locked).

Allows you to optimize the operation of the 4D Web server in remote mode by reusing Web processes created for processing previous Web requests. In fact, the Web server of a 4D client needs a specific Web process for the handling of each Web request; when necessary, this process connects to the 4D Server machine in order to access the data and database engine. It then generates a temporary context using its own variables, selections, etc. Once the request has been dealt with, this process is killed.

When the Reuse Temporary Contexts option is checked, 4D maintains the specific Web processes created on the client machine and reuses them for subsequent requests. By removing the process creation stage, Web server performance is improved.

In return, you must make sure in this case to systematically initialize the variables used in 4D methods in order to avoid getting incorrect results. Similarly, it is necessary to erase any current selections or records defined during the previous request.

In the Database Settings, you can set the access control system that you want to apply to your Web server. Two authentication modes are provided: BASIC mode and DIGEST mode. The authentication mode concerns the way the information concerning the user name and password are collected and processed.

• In BASIC mode, the name and password entered by the user are sent unencrypted in the HTTP requests. This does not ensure total system security since this information could be intercepted and used by a third party.
• The DIGEST mode provides a greater level of security since the authentication information is processed by a one-way process called hashing which makes their contents impossible to decipher.

For the user, the use of either authentication mode is transparent.

Notes:

• For compatibility reasons, the BASIC authentication mode is used by default in 4D databases that are converted to version 11 (if the “Use Passwords” option was checked in the previous version). You must explicitly activate the Digest mode.
• Digest authentication is an HTTP1.1 function and is not supported by all browsers. For example, only versions 5.0 and later of Microsoft Internet Explorer accept this mode. If a browser that does not support this functionality sends a request to a Web server when Digest authentication is activated, the server will reject the request and return an error message to the browser.

You can now define, in the Database Settings dialog box, the access control system you want to apply to your Web server. To do this, choose the Options (I) page of the Web theme:

In the "Passwords" area, three options are available to you:

• No passwords: No authentication is carried out for connections to the Web server. In this case:
  
  • If the On Web Authentication Database Method exists, it is executed and, in addition to $1 and $2, only the IP addresses of the browser and the server ($3 and $4) are provided, the user name and password ($5 and $6) are empty. In this case, you can filter connections according to the IP address of the browser and/or the requested IP address of the server.
  • If the On Web Authentication Database Method does not exist, connections are automatically accepted.
• Passwords with BASIC protocol: Standard authentication in BASIC mode. When a user connects to the server, a dialog box appears on their browser in order for them to enter their user name and password. These two values are then sent to the On Web Authentication Database Method along with the other connection parameters (IP address and port, URL...) so that you can process them.
  This mode provides access to the Include 4D passwords option that allows you to use, instead of or in addition to your own password system, 4D’s database password system (as defined in 4D).
• Passwords with DIGEST protocol: Authentication in DIGEST mode. As in BASIC mode, users must enter their name and password when they connect. These two values are then sent encrypted to the On Web Authentication Database Method with the other connection parameters. You must authenticate a user using the WEB Validate digest command.

Notes:

• You must restart the Web server in order for the changes made to these parameters to be taken into account
• With the 4D Client Web server, keep in mind that all the sites published by the 4D Client machines will share the same table of users. Validation of users/passwords is carried out by the 4D Server application.

If you use the BASIC mode, the system that filters connections to the 4D Web server depends on the combination of two parameters:

• The Web password options in the Database Settings dialog box,
• The existence of the On Web Authentication Database Method.

Here are the different resulting systems:

The “Passwords with BASIC protocol” option is selected and the “Include 4D Passwords” option is not selected.

• If the On Web Authentication Database Method exists, it is executed and all its parameters are given. You can therefore filter more precisely the connections according to the user name, password, and/or the browser’s or Web server’s IP address.
• If the On Web Authentication Database Method doesn’t exist, the connection is automatically refused and a message indicating that the Authentication method doesn’t exist is sent to the browser.

Note: If the user name sent by the browser is an empty string and if the On Web Authentication Database Method doesn’t exist, a password dialog box is sent to the browser.

The “Passwords with BASIC protocol” and “Include 4D Passwords” options are selected.

• If the user name sent by the browser exists in the table of 4D users and the password is correct, the connection is accepted. If the password is incorrect, the connection is refused.
• If the user name sent by the browser doesn’t exist in 4D, two results are then possible:
  
  • If the On Web Authentication Database Method exists, the parameters $1, $2, $3, $4, $5, and $6 are returned. You can therefore filter the connections according to the user name, password, and/or the browser’s or Web server’s IP address.
  • If the On Web Authentication Database Method doesn’t exist, the connection is refused.

Unlike BASIC mode, the DIGEST mode is not compatible with standard 4D passwords: it is not possible to use 4D passwords as Web IDs. The “Include 4D passwords” option is dimmed when this mode is selected. The IDs for Web users must be managed in a customized manner (for example, via a table).

When the DIGEST mode is activated, the $6 parameter (password) is always returned empty in the On Web Authentication Database Method. In fact, when using this mode, this information does not pass by the network as clear text (unencrypted). It is therefore imperative in this case to evaluate connection requests using the WEB Validate digest command.

The operation of the 4D Web server's access system is summarized in the following diagram:

You can designate a user, previously defined in the 4D password table, as a “Generic Web User.” In this case, each browser that connects to the database can use the access authorizations and restrictions associated with this generic user. You can therefore easily control the browser’s access to the different parts of the database.

Note: Do not confuse this option, which allows you to restrict the browser’s access to different parts of the application (methods, forms, etc.), with the Web server’s connection control system, managed by the password system and the On Web Authentication Database Method.

To define a Generic Web User:

1. In the Design mode, create at least one user with the Users editor of the Tool Box.
   You can associate a password with the user if you wish.
2. In the different 4D editors, authorize or restrict access to this user.
3. In the Database Settings dialog, choose the Options (I) page of the Web theme.
   The “Web Passwords” area contains the Generic Web User drop-down list.By default, the Generic Web User is the Designer and the browsers have full access to the entire database.
4. Choose a user in the drop-down list and validate the dialog box

   

All the Web browsers that are authorized to connect to the database will benefit from the access authorizations and restrictions associated with this Generic Web User (except when the BASIC mode and the “Include 4D Passwords” option are checked and the user that connects does not exist in the 4D password table, see below).

The "Passwords with BASIC protocol" option does not influence how the Generic Web User operates. Whatever the state of this option, the access authorizations and restrictions associated with the “Generic Web User” will be applied to all the Web browsers that are authorized to connect to the database.

However, when the "Include 4D passwords" option is selected, two possible results can occur:

• The user’s name and password don’t exist in 4D’s password table. In this case, if the connection has been accepted by the On Web Authentication Database Method, the Generic Web User’s access rights will be applied to the browser.
• If the user’s name and password exist in 4D’s password table, the “Generic Web User” parameter is ignored. The user connects with his own access rights.