Module Apache mod_lua

Configuration de base

La directive de base pour le chargement du module est

    LoadModule lua_module modules/mod_lua.so

mod_lua fournit un gestionnaire nommé lua-script qui peut être utilisé avec une directive AddHandler :

AddHandler lua-script .lua

Ceci aura pour effet de faire traiter les requêtes pour les fichiers dont l'extension est .lua par mod_lua en invoquant cette fonction de gestion de fichier.

Pour plus de détails, voir la directive LuaMapHandler.

Ecrire des gestionnaires

Dans l'API du serveur HTTP Apache, un gestionnaire est une sorte de point d'accroche (hook) spécifique responsable de la génération de la réponse. mod_proxy, mod_cgi et mod_status sont des exemples de modules comportant un gestionnaire.

mod_lua cherche toujours à invoquer une fonction Lua pour le gestionnaire, plutôt que de simplement évaluer le corps d'un script dans le style de CGI. Une fonction de gestionnaire se présente comme suit :

example.lua

-- exemple de gestionnaire

require "string"

--[[
     Il s'agit du nom de méthode par défaut pour les gestionnaires Lua ;
     voir les noms de fonctions optionnels dans la directive
     LuaMapHandler pour choisir un point d'entrée différent.
--]]
function handle(r)
    r.content_type = "text/plain"
    r:puts("Hello Lua World!\n")

    if r.method == 'GET' then
        for k, v in pairs( r:parseargs() ) do
            r:puts( string.format("%s: %s\n", k, v) )
        end
    elseif r.method == 'POST' then
        for k, v in pairs( r:parsebody() ) do
            r:puts( string.format("%s: %s\n", k, v) )
        end
    else
        r:puts("Unsupported HTTP method " .. r.method)
    end
end

Ce gestionnaire se contente d'afficher les arguments codés d'un uri ou d'un formulaire dans un page au format texte.

Cela signifie que vous pouvez (et êtes encouragé à) avoir plusieurs gestionnaires (ou points d'entrée, ou filtres) dans le même script.

Ecriture de fournisseurs d'autorisation

mod_authz_core fournit une interface d'autorisation de haut niveau bien plus facile à utiliser que dans les hooks correspondants. Le premier argument de la directive Require permet de spécifier le fournisseur d'autorisation à utiliser. Pour chaque directive Require, mod_authz_core appellera le fournisseur d'autorisation spécifié, le reste de la ligne constituant les paramètres. Le fournisseur considéré va alors vérifier les autorisations et fournir le résultat dans une valeur de retour.

En général, le fournisseur authz est appelé avant l'authentification. S'il doit connaître le nom d'utilisateur authentifié (ou si l'utilisateur est appelé à être authentifié), le fournisseur doit renvoyer apache2.AUTHZ_DENIED_NO_USER, ce qui va déclancher le processus d'authentification et un deuxième appel du fournisseur authz.

La fonction du fournisseur authz ci-dessous accepte deux arguments, une adresse IP et un nom d'utilisateur. Elle autorise l'accès dans le cas où la requête provient de l'adresse IP spécifiée, ou si l'utilisateur authentifié correspond au second argument :

authz_provider.lua


require 'apache2'

function authz_check_foo(r, ip, user)
    if r.useragent_ip == ip then
        return apache2.AUTHZ_GRANTED
    elseif r.user == nil then
        return apache2.AUTHZ_DENIED_NO_USER
    elseif r.user == user then
        return apache2.AUTHZ_GRANTED
    else
        return apache2.AUTHZ_DENIED
    end
end

La configuration suivante enregistre cette fonction en tant que fournisseur foo, et la configure por l'URL / :

LuaAuthzProvider foo authz_provider.lua authz_check_foo
<Location />
  Require foo 10.1.2.3 john_doe
</Location>

Ecriture de fonctions d'accroche (hooks)

Les fonctions d'accroche déterminent la manière dont les modules (et les scripts Lua) participent au traitement des requêtes. Chaque type d'accroche proposé par le serveur a un rôle spécifique, comme l'association de requêtes au système de fichiers, le contrôle d'accès, ou la définition de types MIME :

Les fonctions d'accroche reçoivent l'objet de la requête comme seul argument (sauf LuaAuthzProvider qui reçoit aussi des arguments en provenance de la directive Require). Elles peuvent renvoyer une valeur, selon la fonction, mais il s'agit en général d'un code d'état HTTP ou des valeurs OK, DONE, ou DECLINED, que vous pouvez écrire dans lua sous la forme apache2.OK, apache2.DONE, ou apache2.DECLINED.

translate_name.lua

-- exemple d'accroche qui réécrit un URI en chemin du système de
fichiers.

require 'apache2'

function translate_name(r)
    if r.uri == "/translate-name" then
        r.filename = r.document_root .. "/find_me.txt"
        return apache2.OK
    end
    -- on ne gère pas cette URL et on donne sa chance à un autre module
    return apache2.DECLINED
end

translate_name2.lua

--[[ exemple d'accroche qui réécrit un URI vers un autre URI. Il renvoie
	un apache2.DECLINED pour permettre à un autre interpréteur d'URL de
	travailler sur la substitution, y compris l'accroche translate_name
	de base dont les tables de correspondances se basent sur DocumentRoot.

     Note: utilisez le drapeau early/late de la directive pour
     l'exécuter avant ou après mod_alias.
--]]

require 'apache2'

function translate_name(r)
    if r.uri == "/translate-name" then
        r.uri = "/find_me.txt"
        return apache2.DECLINED
    end
    return apache2.DECLINED
end

Structures de données

request_rec

request_rec est considérée en tant que donnée utilisateur. Elle possède une métatable qui vous permet d'accomplir des choses intéressantes. Pour la plus grande partie, elle possède les mêmes champs que la structure request_rec, la plupart d'entre eux étant accessibles en lecture et écriture (le contenu des champs de la table peut être modifié, mais les champs eux-mêmes ne peuvent pas être établis en tant que tables distinctes).

Nom	Type Lua	Modifiable	Description
allowoverrides	string	non	L'option AllowOverride s'applique à la requête courante.
ap_auth_type	string	non	Ce champ contient le type d'authentification effectuée (par exemple basic)
args	string	oui	La chaîne de paramètres de la requête (par exemple foo=bar&name=johnsmith)
assbackwards	boolean	non	contient true s'il s'agit d'une requête de style HTTP/0.9 (par exemple GET /foo (sans champs d'en-tête) )
auth_name	string	non	La chaîne d'identification utilisée pour la vérification de l'autorisation d'accès (si elle est disponible).
banner	string	non	La bannière du serveur, par exemple Apache HTTP Server/2.4.3 openssl/0.9.8c
basic_auth_pw	string	non	Le mot de passe pour l'authentification de base envoyé avec la requête, s'il existe
canonical_filename	string	non	Le nom de fichier canonique de la requête
content_encoding	string	non	Le type de codage du contenu de la requête courante
content_type	string	oui	Le type de contenu de la requête courante, tel qu'il a été déterminé au cours de la phase type_check (par exemple image/gif ou text/html)
context_prefix	string	non
context_document_root	string	non
document_root	string	non	La racine des documents du serveur
err_headers_out	table	non	L'en-tête MIME de l'environnement pour la réponse, écrit même en cas d'erreur et conservé pendant les redirections internes
filename	string	oui	Le nom de fichier correspondant à la requête, par exemple /www/example.com/foo.txt. Il peut être modifié au cours des phases translate-name ou map-to-storage du traitement de la requête pour permettre au gestionnaire par défaut (ou aux gestionnaires de script) de servir une version du fichier autre que celle demandée.
handler	string	oui	Le nom du gestionnaire qui doit traiter la requête, par exemple lua-script si elle doit être traitée par mod_lua. Cette valeur est en général définie via les directives AddHandler ou SetHandler, mais peut aussi l'être via mod_lua pour permettre à un autre gestionnaire de traiter une requête spécifique qui ne serait pas traitée par défaut par ce dernier.
headers_in	table	oui	Les en-têtes MIME de l'environnement de la requête. Il s'agit des en-têtes comme Host, User-Agent, Referer, etc...
headers_out	table	oui	Les en-têtes MIME de l'environnement de la réponse.
hostname	string	non	Le nom d'hôte, tel que défini par l'en-tête Host: ou par un URI complet.
is_https	boolean	non	Indique si la requête à été faite via HTTPS
is_initial_req	boolean	non	Indique si la requête courante est la requête initiale ou une sous-requête.
limit_req_body	number	non	La taille maximale du corps de la requête, ou 0 si aucune limite.
log_id	string	non	L'identifiant de la requête dans les journaux d'accès ou d'erreur.
method	string	non	La méthode de la requête, par exemple GET ou POST.
notes	table	oui	Une liste de notes qui peuvent être transmises d'un module à l'autre.
options	string	non	La valeur de la directive Options pour la requête courante.
path_info	string	non	La valeur de PATH_INFO extraite de la requête.
port	number	non	Le port du serveur utilisé par la requête.
protocol	string	non	Le protocole utilisé, par exemple HTTP/1.1
proxyreq	string	oui	Indique s'il s'agit d'une requête mandatée ou non. Cette valeur est en général définie au cours de la phase post_read_request/translate_name du traitement de la requête.
range	string	non	Le contenu de l'en-tête Range:.
remaining	number	non	Le nombre d'octets du corps de la requête restant à lire.
server_built	string	non	La date de compilation du serveur.
server_name	string	non	Le nom du serveur pour cette requête.
some_auth_required	boolean	non	Indique si une autorisation est/était requise pour cette requête.
subprocess_env	table	oui	Le jeu de variables d'environnement pour cette requête.
started	number	non	Le moment où le serveur a été (re)démarré, en secondes depuis epoch (1er janvier 1970)
status	number	oui	Le code de retour (courant) pour cette requête, par exemple 200 ou 404.
the_request	string	non	La chaîne de la requête telle qu'elle a été envoyée par le client, par exemple GET /foo/bar HTTP/1.1.
unparsed_uri	string	non	La partie URI non interprétée de la requête
uri	string	oui	L'URI après interprétation par httpd
user	string	oui	Si une authentification a été effectuée, nom de l'utilisateur authentifié.
useragent_ip	string	non	L'adresse IP de l'agent qui a envoyé la requête

La structure request_rec possède (au minimum) les méthodes suivantes :

	r:flush() -- vide le tampon de sortie
        

        r:addoutputfilter(name|function) -- ajoute un filtre en sortie
        

	r:sendfile(filename) -- envoie un fichier entier au client en
	utilisant sendfile s'il est supporté par la plateforme
        

        r:parseargs() -- renvoie une table Lua contenant la chaîne
	d'arguments de la requête
        

        r:parsebody()([sizeLimit]) -- interprète le corps de la requête
	en tant que POST et renvoie une table lua. Un nombre optionnel
	peut être fourni pour spécifier le nombre maximal d'octets à
	interpréter. La valeur par défaut est 8192.
        

        r:puts("bonjour", " le monde", "!") -- affichage dans le corps de la réponse
        

        r:write("une simple chaîne") -- affichage dans le
	corps de la réponse
        

        r:escape_html("<html>test</html>") -- Echappe le
	code HTML et renvoie le résultat
        

        r:base64_encode(string) -- Encode une chaîne à l'aide du
	standard de codage Base64.
        

        r:base64_decode(string) -- Décode une chaîne codée en Base64.
        

        r:md5(string) -- Calcule et renvoie le condensé MD5 d'une chaîne
	en mode binaire (binary safe).
        

        r:sha1(string) -- Calcule et renvoie le condensé SHA1 d'une chaîne
	en mode binaire (binary safe).
        

        r:escape(string) -- Echappe une chaîne de type URL.
        

        r:unescape(string) -- Déséchappe une chaîne de type URL.
        

        r:banner() -- Renvoie la bannière du serveur courant.
        

        r:port() -- Renvoie le port du serveur courant utilisé pour la
	requête.
        

        r:mpm_query(number) -- Interroge le serveur à propos de son
	module MPM via la requête ap_mpm_query.
        

        r:expr(string) -- Evalue une chaîne de type expr.
        

        r:scoreboard_process(a) -- Interroge le serveur à propos du
	processus à la position a.
        

        r:scoreboard_worker(a, b) -- Interroge le serveur à propos du
	thread b, dans le processus a.
        

        r:started() -- Renvoie l'heure du dernier (re)démarrage du
	serveur.
        

        r:clock() -- Renvoie l'heure courante avec une précision d'une
	microseconde.
        

r:requestbody(filename) -- Lit et renvoie le corps d'une requête. Si
'filename' est spécifié, le corps de requête n'est pas renvoyé, mais
sauvegardé dans le fichier correspondant.
        

        r:add_input_filter(filter_name) -- Ajoute le filtre en entrée
	'filter_name'.
        

        r:module_info(module_name) -- Interroge le serveur à propos d'un
	module.
        

        r:loaded_modules() -- Renvoie une liste des modules chargés par
	httpd.
        

r:runtime_dir_relative(filename) -- Génère le nom d'un fichier run-time
(par exemple la mémoire partagée "file") relativement au répertoire de
run-time. 
        

        r:server_info() -- Renvoie une table contenant des informations
	à propos du serveur, comme le nom de l'exécutable httpd, le
	module mpm utilisé, etc...
        

        r:set_document_root(file_path) -- Définit la racine des
	documents pour la requête à file_path.
        

        r:add_version_component(component_string) -- Ajoute un élément à
	la bannière du serveur.
        

        r:set_context_info(prefix, docroot) -- Définit le préfixe et la
	racine des documents du contexte pour une requête.
        

        r:os_escape_path(file_path) -- Convertit un chemin du système de
	fichiers en URL indépendamment du système d'exploitation.
        

        r:escape_logitem(string) -- Echappe une chaîne pour
	journalisation.
        

r:strcmp_match(string, pattern) -- Vérifie si 'string' correspond à
'pattern' via la fonction strcmp_match (GLOBs). Par exemple, est-ce que
'www.example.com' correspond à '*.example.com' ?
        

        r:set_keepalive() -- Définit l'état de persistance d'une
	requête. Renvoie true dans la mesure du possible, false dans le
	cas contraire.
        

        r:make_etag() -- Génère et renvoie le etag pour la requête
	courante.
        

r:send_interim_response(clear) -- Renvoie une réponse d'intérim (1xx) au
client. Si 'clear' est vrai, les en-têtes disponibles seront envoyés et
effacés.
        

r:custom_response(status_code, string) -- Génère et définit une réponse
personnalisée pour un code d'état particulier. Le fonctionnement est
très proche de celui de la directive ErrorDocument.
        

        r:exists_config_define(string) -- Vérifie si une définition de
	configuration existe.
        

        r:state_query(string) -- Interroge le serveur à propos de son
	état.
        

        r:stat(filename) -- Exécute stat() sur un fichier, et renvoie
	une table contenant des informations à propos de ce fichier.
        

        r:regex(string, pattern) -- Exécute une recherche à base
	d'expression rationnelle sur une chaîne, et renvoie les
	éventuelles correspondances trouvées.
        

        r:sleep(secondes) -- Interrompt l'exécution du script pendant le
	nombre de secondes spécifié.
        

	r:dbacquire(dbType[, dbParams]) -- Acquiert une connexion à une
base de données et renvoie une classe database. Voir 'Connectivité aux bases de données' pour plus de
détails.
        

Fonctions de journalisation

	-- exemples de messages de journalisation
	r:trace1("Ceci est un message de journalisation de niveau
	trace") -- les niveaux valides vont de trace1 à trace8 

        r:debug("Ceci est un message de journalisation de niveau debug")

        r:info("Ceci est un message de journalisation de niveau info")

        r:notice("Ceci est un message de journalisation de niveau notice")

        r:warn("Ceci est un message de journalisation de niveau warn")

        r:err("Ceci est un message de journalisation de niveau err")

        r:alert("Ceci est un message de journalisation de niveau alert")

        r:crit("Ceci est un message de journalisation de niveau crit")

        r:emerg("Ceci est un message de journalisation de niveau emerg")

Paquet apache2

Le paquet nommé apache2 est fourni avec (au minimum) le contenu suivant :

apache2.OK

Constante interne OK. Les gestionnaires renverront cette valeur s'ils ont traité la requête.

apache2.DECLINED

Constante interne DECLINED. Les gestionnaires renverront cette valeur s'ils n'ont pas l'intention de traiter la requête.

apache2.DONE

Constante interne DONE.

apache2.version

Chaîne contenant la version du serveur HTTP Apache

apache2.HTTP_MOVED_TEMPORARILY

Code d'état HTTP

apache2.PROXYREQ_NONE, apache2.PROXYREQ_PROXY, apache2.PROXYREQ_REVERSE, apache2.PROXYREQ_RESPONSE

Constantes internes utilisées par mod_proxy

apache2.AUTHZ_DENIED, apache2.AUTHZ_GRANTED, apache2.AUTHZ_NEUTRAL, apache2.AUTHZ_GENERAL_ERROR, apache2.AUTHZ_DENIED_NO_USER

constantes internes utilisées par mod_authz_core

Les autres codes d'état HTTP ne sont pas encore implémentés.

Modification de contenu avec les filtres lua

Les fonctions de filtrage implémentées via les directives LuaInputFilter ou LuaOutputFilter sont conçues comme des fonctions de 3ème phase non blocantes utilisant des sous-routines pour suspendre et reprendre l'exécution d'une fonction lorsque des paquets de données sont envoyés à la chaîne de filtrage. La structure de base d'une telle fonction est :

function filter(r)
    -- Nous indiquons tout d'abord que nous sommes prêts à recevoir des
    -- blocs de données.
    -- Avant ceci, nous pouvons définir notre environnement, tester
    -- certaines conditions, et, si nous le jugeons nécessaire, refuser le
    -- filtrage d'une requête :
    if something_bad then
        return -- Le filtrage est sauté
    end
    -- Sans se préoccuper des données que nous devons éventuellement ajouter, un arrêt est réalisé ici.
    -- Noter que les filtres de sortie sont les seuls capables d'ajouter des éléments au début des données.
    -- Les filtres en entrée peuvent ajouter des éléments à la fin des données au stade final.

    coroutine.yield([optional header to be prepended to the content])

    -- Après cet arrêt, nous allons recevoir d'autres blocs de données, un par un ;
    -- nous pouvons les traiter comme il nous plaît et procéder à la réponse.
    -- Ces blocs sont conservés dans la variable globale 'bucket', nous réalisons donc
    -- une boucle pour vérifier que 'bucket' n'est pas vide :
    while bucket ~= nil do
        local output = mangle(bucket) -- Do some stuff to the content
        coroutine.yield(output) -- Return our new content to the filter chain
    end

    -- Une fois les blocs de données épuisés, 'bucket' est positionné à une valeur vide ('nil'),
    -- ce qui va nous faire sortir de cette boucle et nous amener à l'étape suivante.
    -- On peut ajouter ce qu'on veut à la fin des données à cette étape, qui constitue le dernier
    -- arrêt. Les filtres d'entrée comme de sortie peuvent servir à ajouter des éléments à la fin
    --  des données à cette étape.
    coroutine.yield([optional footer to be appended to the content])
end
    

Connectivité aux bases de données

Mod_lua implémente une fonctionnalité basique de connexion aux bases de données permettant d'envoyer des requêtes ou d'exécuter des commandes auprès des moteurs de base de données les plus courants (mySQL, PostgreSQL, FreeTDS, ODBC, SQLite, Oracle), ainsi que mod_dbd.

L'exemple suivant montre comment se connecter à une base de données et extraire des informations d'une table :

function handler(r)
    -- connexion à la base de données
    local database, err = r:dbacquire("mysql", "server=localhost,user=root,dbname=mydb")
    if not err then
        -- Sélection de certaines informations
        local results, err = database:select(r, "SELECT `name`, `age` FROM `people` WHERE 1")
        if not err then
            local rows = results(0) -- extrait tous les enregistrements en mode synchrone
            for k, row in pairs(rows) do
                r:puts( string.format("Name: %s, Age: %s<br/>", row[1], row[2]) )
            end
        else
            r:puts("Database query error: " .. err)
        end
        database:close()
    else
        r:puts("Connexion à la base de données impossible : " .. err)
    end
end
    

Pour utiliser mod_dbd, spécifiez mod_dbd comme type de base de données, ou laissez le champ vide :

    local database = r:dbacquire("mod_dbd")
    

L'objet database et ses méthodes

L'objet database renvoyé par dbacquire possède les méthodes suivantes :

Sélection normale et requête vers une base de données :

-- Exécution d'une requête et renvoie du nombre d'enregistrements
affectés :
local affected, errmsg = database:query(r, "DELETE FROM `tbl` WHERE 1")

-- Exécution d'une requête et renvoie du résultat qui peut être utilisé
en mode synchrone ou asynchrone :
local result, errmsg = database:select(r, "SELECT * FROM `people` WHERE 1")
    

Utilisation de requêtes préparées (recommandé) :

-- Création et exécution d'une requête préparée :
local statement, errmsg = database:prepare(r, "DELETE FROM `tbl` WHERE `age` > %u")
if not errmsg then
    local result, errmsg = statement:query(20) -- exécute la requête pour age > 20
end

-- Extrait une requête préparée depuis une directive DBDPrepareSQL :
local statement, errmsg = database:prepared(r, "someTag")
if not errmsg then
    local result, errmsg = statement:select("John Doe", 123) -- injecte les valeurs "John Doe" et 123 dans la requête
end

Echappement de valeurs, fermeture de la base données, etc...

-- Echappe une valeur pour pouvoir l'utiliser dans une requête :
local escaped = database:escape(r, [["'|blabla]])

-- Ferme une base de données et libère les liens vers cette dernière :
database:close()

-- Vérifie si une connexion à une base de données est en service et
opérationnelle :
local connected = database:active()
    

Travail avec les jeux d'enregistrements renvoyés par les requêtes

Les jeux d'enregistrements renvoyés par db:select ou par des requêtes préparées créées par db:prepare permettent de sélectionner des enregistrements en mode synchrone ou asynchrone, selon le nombre d'enregistrements spécifié :
result(0) sélectionne tous les enregistrements en mode synchrone en renvoyant une table d'enregistrements.
result(-1) sélectionne le prochain enregistrement disponible en mode asynchrone.
result(N) sélectionne l'enregistrement numéro N en mode asynchrone.

-- extrait un jeu d'enregistrements via une requête régulière :
local result, err = db:select(r, "SELECT * FROM `tbl` WHERE 1")

local rows = result(0) -- sélectionne tous les enregistrements en mode synchrone
local row = result(-1) -- sélectionne le prochain enregistrement disponible en mode asynchrone
local row = result(1234) -- sélectionne l'enregistrement 1234 en mode asynchrone
    

Il est possible de construire une fonction qui renvoie une fonction itérative permettant de traiter tous les enregistrement en mode synchrone ou asynchrone selon la valeur de l'argument async :

function rows(resultset, async)
    local a = 0
    local function getnext()
        a = a + 1
        local row = resultset(-1)
        return row and a or nil, row
    end
    if not async then
        return pairs(resultset(0))
    else
        return getnext, self
    end
end

local statement, err = db:prepare(r, "SELECT * FROM `tbl` WHERE `age` > %u")
if not err then
     -- sélectionne des enregistrements en mode asynchrone :
    local result, err = statement:select(20)
    if not err then
        for index, row in rows(result, true) do
            ....
        end
    end

     -- sélectionne des enregistrements en mode synchrone :
    local result, err = statement:select(20)
    if not err then
        for index, row in rows(result, false) do
            ....
        end
    end
end
    

Fermeture d'une connexion à une base de données

Lorsqu'elles ne sont plus utilisées, les connexions aux bases de données doivent être fermées avec database:close(). Si vous ne les fermez pas manuellement, mod_lua les fermera peut-être en tant que résidus collectés, mais si ce n'est pas le cas, vous pouvez finir pas avoir trop de connexions vers la base de données inutilisées. Les deux mesures suivantes sont pratiquement identiques :

-- Méthode 1 : fermeture manuelle de la connexion
local database = r:dbacquire("mod_dbd")
database:close() -- c'est tout

-- Méthode 2 : on laisse le collecteur de résidus la fermer
local database = r:dbacquire("mod_dbd")
database = nil -- on coupe le lien
collectgarbage() -- fermeture de la connexion par le collecteur de résidus

Précautions à prendre lorsque l'on travaille avec les bases de données

Bien que les fonctions query et run soient toujours disponibles, il est recommandé d'utiliser des requêtes préparées chaque fois que possible, afin d'une part d'optimiser les performances (si votre connexion reste longtemps en vie), et d'autre part minimiser le risque d'attaques par injection SQL. Les fonctions run et query ne doivent être utilisées que lorsque la requête ne contient pas de variables (requête statique). Dans le cas des requêtes dynamiques, utilisez db:prepare ou db:prepared.