Account Control

The mod_auth module takes care of authentication. To activate it, either add it to the list after server.modules or add it later to lighttpd.conf with the += operator:

server.modules += ("mod_auth", "mod_authn_file")

Two modules are needed for access control: mod_auth fields a username and password and then asks a backend whether the user has sufficient access rights. The backends in turn provide other modules, one of which is mod_authn_file. This module provides several backends, all of which read user data from text files. Other available backends use PAM or an LDAP server instead.

Which backend mod_auth needs to use is defined by a setting in lighttpd.conf. Listing 2 uses the plain backend, which expects the passwords in plain text in a simple text file. auth.backend.plain.userfile tells the appropriate module to fetch the user data from the /etc/lighttpd/user.txt file. It contains the user names and passwords on each line in a <User>:<Password> format. Finally, auth.require specifies that access to the /blog URL is restricted, the password is in the clear ("method" => "basic"), and any authorized user is granted access ("require" => "valid-user").

auth.backend = "plain"
auth.backend.plain.userfile = "/etc/lighttpd/user.txt"
auth.require = ( "/blog" => ("method" => "basic", "realm" => "application", "require" => "valid-user") )

The example shows an easily set up but relatively insecure form of authentication. Lighttpd and its modules do not support the .htaccess files known from Apache. As a consequence, a web application that builds on that basis could be vulnerable on Lighttpd.

Distribution Box

Lighttpd prefers to integrate scripting languages over the FastCGI interface, which the mod_fastcgi module installs retroactively. At the same time, it includes a load balancer that distributes the load across multiple FastCGI servers. Suitable settings for lighttpd.conf are shown in the example in Listing 3; the module distributes the requests evenly among the servers by a round-robin method (line 2).

The settings in the fastcgi.server module reveal to which FastCGI servers Lighttpd sends a script for execution. In the example in Listing 3, the web server passes all files with a .php extension to one of two FastCGI servers. The first of the two has IP address 192.168.0.1 and port 1026, and the second sits at the same port on IP address 192.168.0.2.

server.modules += ( "mod_fastcgi" )
fastcgi.balance = "round-robin"
fastcgi.server = (
  ".php" => (
    ( "host" => "192.168.0.1",
      "port" => 1026,
    )
    ( "host" => "192.168.0.2",
      "port" => 1026,
    )
  )
)

On Ubuntu, you just need to install the php7.4-fpm package so PHP is waiting on a socket for incoming PHP code. In this case, you only need to point the web server to the appropriate socket:

fastcgi.server = ( ".php" =>
  (( "socket" => "/run/php/php-fpm7.4" ))
)

Lighttpd always executes the modules in the order in which they appear after server.modules or in lighttpd.conf. Therefore, you should always load the modules that control access first (e.g., mod_auth) and only then load modules that generate and return content (e.g., mod_fastcgi). Otherwise, Lighttpd might skip authentication.

Detailed documentation (Figure 3) of all official modules and the web server can be found in the Lighttpd wiki [5].

Figure 3: The Lighttpd wiki provides an overview of existing modules, which cover all the features that could be important in daily work, such as URL rewriting (mod_rewrite).

Conclusions

The work on Lighttpd is currently limited to maintenance and careful ongoing development of the 1.4 branch. The web server is lagging behind its competitors slightly when it comes to new technologies. Nevertheless, deployment of Lighttpd would make sense if a workgroup needed a web server at short notice, because it can be set up quickly, thanks to its compact and intelligible configuration, and it can be adapted to a team's needs just as quickly through the use of modules.