Serveur HTTP Apache Version 2.4

| Description: | Fournit des points d'entrĂ©e Lua dans diffĂ©rentes parties du traitement des requĂȘtes httpd |
|---|---|
| Statut: | Extension |
| Identificateur de Module: | lua_module |
| Fichier Source: | mod_lua.c |
| Compatibilité: | versions 2.3 et supérieures |
Ce module permet d'ajouter au serveur des extensions sous forme de
scripts écrits dans le langage de programmation Lua.
mod_lua fournit de nombreuses extensions
(hooks) disponibles avec les modules natifs du serveur HTTP Apache,
comme les associations de requĂȘtes Ă des fichiers, la gĂ©nĂ©ration de
réponses dynamiques, le contrÎle d'accÚs, l'authentification et
l'autorisation.
Vous trouverez davantage d'informations Ă propos du langage de programmation Lua sur le site web de Lua.
Ce module possÚde une grande capacité d'action sur le fonctrionnement de httpd, ce qui lui confÚre une grande puissance, mais peut aussi induire un risque de sécurité. Il est déconseillé d'utiliser ce module sur un serveur partagé avec des utilisateurs auxquels vous ne pouvez pas accorder une confiance absolue, car il peut permettre de modifier le fonctionnement interne de httpd.
Configuration de base
Ecrire des gestionnaires
Ecriture de fournisseurs d'autorisation
Ecriture de fonctions d'accroche
(hooks)
Structures de données
Méthodes de l'objet request_rec
Fonctions de journalisation
Paquet apache2
Modification de contenu avec les filtres lua
Connectivité aux bases de données
LuaAuthzProvider
LuaCodeCache
LuaHookAccessChecker
LuaHookAuthChecker
LuaHookCheckUserID
LuaHookFixups
LuaHookInsertFilter
LuaHookLog
LuaHookMapToStorage
LuaHookPreTranslate
LuaHookTranslateName
LuaHookTypeChecker
LuaInherit
LuaInputFilter
LuaMapHandler
LuaOutputFilter
LuaPackageCPath
LuaPackagePath
LuaQuickHandler
LuaRoot
LuaScopeLa 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 ou SetHandler :
<Files "*.lua">
SetHandler lua-script
</Files>
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.
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" if r.method == 'GET' then r:puts("Hello Lua World!\n") for k, v in pairs( r:parseargs() ) do r:puts( string.format("%s: %s\n", k, v) ) end elseif r.method == 'POST' then r:puts("Hello Lua World!\n") for k, v in pairs( r:parsebody() ) do r:puts( string.format("%s: %s\n", k, v) ) end else elseif r.method == 'PUT' then -- message d'erreur personnalisé r:puts("Unsupported HTTP method " .. r.method) r.status = 405 return apache2.OK else -- message d'erreur ErrorDocument return 501 end return apache2.OK 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.
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>
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 :
| Phase d'accroche | Directive de mod_lua |
Description |
|---|---|---|
| Gestionnaire rapide | LuaQuickHandler |
Il s'agit de la premiĂšre accroche appelĂ©e lorsqu'une requĂȘte a Ă©tĂ© associĂ©e Ă un serveur ou un serveur virtuel. |
| Phase de pré-traduction | LuaHookPreTranslateName |
Cette phase traduit l'URI de la requĂȘte en nom de fichier sur le
systÚme avant la phase de décodage. Des modules comme
mod_proxy peuvent agir au cours de cette phase. |
| Phase de traduction | LuaHookTranslateName |
Cette phase traduit l'URI de la requĂȘte en nom de fichier
sur le systĂšme. Ce sont des modules comme
mod_alias et mod_rewrite qui
interviennent au cours de cette phase. |
| Choix du lieu de stockage de la ressource | LuaHookMapToStorage |
Cette phase définit le lieu de stockage de la ressource : physique, en cache ou externe/mandaté. Elle est assurée par les modules de mandat ou de mise en cache. |
| Autorisation d'accĂšs | LuaHookAccessChecker |
Cette phase vĂ©rifie si un client a l'autorisation d'accĂšs Ă la ressource. Elle s'exĂ©cute avant l'authentification de l'utisateur ; il faut donc ĂȘtre prudent. |
| Vérification de l'identifiant utilisateur | LuaHookCheckUserID |
Cette phase vérifie l'identifiant de l'utilisateur ayant fait l'objet d'une négociation. |
| Vérification de l'autorisation d'accÚs | LuaHookAuthChecker
ou
LuaAuthzProvider |
Cette phase vérifie l'autorisation d'accÚs d'un utilisateur en fonction des ses paramÚtres de connexion, comme l'identifiant, le certificat, etc... |
| Vérification du type de la ressource | LuaHookTypeChecker |
Cette phase assigne un type de contenu et un gestionnaire Ă la ressource. |
| Derniers réglages | LuaHookFixups |
C'est la derniĂšre phase avant l'activation des gestionnaires de contenu. Toute modification de derniĂšre minute Ă la requĂȘte doit ĂȘtre effectuĂ©e ici. |
| Gestionnaire de contenu | fichiers fx. .lua ou directive LuaMapHandler |
C'est durant cette phase que le contenu est traité. Les fichiers sont lus, interprétés, certains sont exécutés, et le résultat obtenu est envoyé au client. |
| Journalisation | LuaHookLog |
Lorsqu'une requĂȘte a Ă©tĂ© traitĂ©e, plusieurs phases de journalisation interviennent, et enregistrent leurs rĂ©sultats dans les fichiers d'erreur ou d'accĂšs. Mod_lua peut s'intercaler au dĂ©part de ce processus et ainsi contrĂŽler la journalisation. |
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
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 | oui | 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. Une table lua en lecture seule est disponible pour l'itĂ©ration sous la forme r:err_headers_out_table(). |
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 pre-translate-name, 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... Une table lua en lecture seule est disponible pour
l'itération sous la forme r:headers_in_table(). |
headers_out |
table | oui | Les en-tĂȘtes MIME de l'environnement de la rĂ©ponse. Une table lua en lecture seule est disponible pour l'itĂ©ration sous la forme r:headers_out_table(). |
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. Une table lua en lecture seule est disponible pour l'itĂ©ration sous la forme r:notes_table(). |
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/pre_translate_name/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. Une table lua en lecture seule est disponible pour l'itĂ©ration sous la forme r:subprocess_env_table(). |
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 |
L'objet request_rec possÚde (au minimum) les méthodes suivantes :
r:flush() -- vide le tampon de sortie
-- Renvoie true si le vidage a été effectué avec succÚs,
-- false dans le cas contraire.
while nous_avons_des_données_à _envoyer do
r:puts("Bla bla bla\n") -- envoi des données à envoyer vers le tampon
r:flush() -- vidage du tampon (envoi au client)
r.usleep(500000) -- mise en attente pendant 0.5 secondes et bouclage
end
r:add_output_filter(filter_name) -- ajoute un filtre en sortie
r:add_output_filter("fooFilter") -- insĂšre le filtre fooFilter dans le flux de sortie
r:sendfile(filename) -- envoie un fichier entier au client en utilisant sendfile s'il est
-- supporté par la plateforme :
if use_sendfile_thing then
r:sendfile("/var/www/large_file.img")
end
r:parseargs() -- renvoie deux tables : une table standard de couples
-- clé/valeur pour les données GET simples,
-- et une autre pour les données
-- multivaluées (par exemple foo=1&foo=2&foo=3) :
local GET, GETMULTI = r:parseargs()
r:puts("Votre nom est : " .. GET['name'] or "Unknown")
r:parsebody()([sizeLimit]) -- interprĂšte le corps de la
-- requĂȘte en tant que POST et renvoie
-- deux tables lua, comme r:parseargs(). Un
-- nombre optionnel peut ĂȘtre fourni
-- pour spécifier le nombre maximal
-- d'octets à interpréter. La
-- valeur par défaut est 8192.
local POST, POSTMULTI = r:parsebody(1024*1024)
r:puts("Votre nom est : " .. POST['name'] or "Unknown")
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.
local encoded = r:base64_encode("This is a test") -- returns VGhpcyBpcyBhIHRlc3Q=
r:base64_decode(string) -- Décode une chaßne codée en Base64.
local decoded = r:base64_decode("VGhpcyBpcyBhIHRlc3Q=") -- returns 'This is a test'
r:md5(string) -- Calcule et renvoie le condensé MD5 d'une chaßne en mode binaire (binary safe).
local hash = r:md5("This is a test") -- returns ce114e4501d2f4e2dcea3e17b546f339
r:sha1(string) -- Calcule et renvoie le condensé SHA1 d'une chaßne en mode binaire (binary safe).
local hash = r:sha1("This is a test") -- returns a54d88e06612d820bc3be72877c74f257b561b19
r:escape(string) -- Echappe une chaĂźne de type URL. local url = "http://foo.bar/1 2 3 & 4 + 5" local escaped = r:escape(url) -- renvoie 'http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5'
r:unescape(string) -- Déséchappe une chaßne de type URL. local url = "http%3a%2f%2ffoo.bar%2f1+2+3+%26+4+%2b+5" local unescaped = r:unescape(url) -- renvoie 'http://foo.bar/1 2 3 & 4 + 5'
r:construct_url(string) -- Construit une URL Ă partir d'un URI local url = r:construct_url(r.uri)
r.mpm_query(number) -- Interroge le serveur Ă propos de son module MPM via la requĂȘte ap_mpm_query.
local mpm = r.mpm_query(14)
if mpm == 1 then
r:puts("Ce serveur utilise le MPM Event")
end
r:expr(string) -- Evalue une chaĂźne de type expr. if r:expr("%{HTTP_HOST} =~ /^www/") then r:puts("Ce nom d'hĂŽte commence par www") end
r:scoreboard_process(a) -- Interroge le serveur Ă propos du
-- processus Ă la position a.
local process = r:scoreboard_process(1)
r:puts("Le serveur 1 a comme PID " .. process.pid)
r:scoreboard_worker(a, b) -- Interroge le serveur Ă propos du
-- thread b, dans le processus a.
local thread = r:scoreboard_worker(1, 1)
r:puts("L'ID du thread 1 du serveur 1 est " .. thread.tid .. " et son
état est " .. thread.status)
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.
local input = r:requestbody()
r:puts("Vous m'avez envoyĂ© le corps de requĂȘte suivant :\n")
r:puts(input)
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.
local mod = r.module_info("mod_lua.c")
if mod then
for k, v in pairs(mod.commands) do
r:puts( ("%s: %s\n"):format(k,v)) -- affiche toutes les directives
-- implémentées par ce module.
end
end
r:loaded_modules() -- Renvoie une liste des modules chargés par httpd.
for k, module in pairs(r:loaded_modules()) do
r:puts("J'ai chargé le module " .. module .. "\n")
end
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' ?
local match = r.strcmp_match("foobar.com", "foo*.com")
if match then
r:puts("foobar.com matches foo*.com")
end
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:custom_response(404, "Baleted!")
r.exists_config_define(string) -- Vérifie si une définition de configuration existe.
if r.exists_config_define("FOO") then
r:puts("httpd a probablement été lancé avec l'option -DFOO, ou FOO a
été défini dans la configuration")
end
r:state_query(string) -- Interroge le serveur à propos de son état.
r:stat(filename [,wanted]) -- Exécute stat() sur un fichier, et renvoie une table contenant
-- des informations Ă propos de ce fichier.
local info = r:stat("/var/www/foo.txt")
if info then
r:puts("Ce fichier existe et a été modifié pour la derniÚre fois à : " .. info.modified)
end
r:regex(string, pattern [,flags]) -- Exécute une recherche à base d'expression rationnelle
-- sur une chaßne, et renvoie les éventuelles correspondances trouvées.
local matches = r:regex("foo bar baz", [[foo (\w+) (\S*)]])
if matches then
r:puts("L'expression rationnelle correspond et le dernier mot
capturé ($2) est : " .. matches[2])
end
-- Exemple avec insensibilité à la casse :
local matches = r:regex("FOO bar BAz", [[(foo) bar]], 1)
-- les drapeaux peuvent ĂȘtre une combibaison bit Ă bit de :
-- 0x01: insensibilité à la casse
-- 0x02: recherche multiligne
r.usleep(microsecondes) -- Interrompt l'exécution du script pendant le nombre de microsecondes 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.
r:ivm_set("key", value) -- Défini une variable Inter-VM avec une valeur spécifique.
-- Ces valeurs sont conservĂ©es mĂȘme si la VM est
-- arrĂȘtĂ©e ou non utilisĂ©e, et ne doivent donc ĂȘtre
-- utilisées que si MaxConnectionsPerChild > 0.
-- Les valeurs peuvent ĂȘtre de type number, string
-- ou boolean et sont stockées séparément pour
-- chaque processus (elles ne seront donc pas d'une
-- grande utilité si l'on utilise le mpm prefork).
r:ivm_get("key") -- Lit le contenu d'une variable définie via ivm_set. Renvoie
-- le contenu de la variable si elle existe, ou nil
-- dans le cas contraire.
-- Voici un exemple de lecture/écriture qui sauvegarde une variable
-- globale en dehors de la VM :
function handle(r)
-- La premiĂšre VM qui effectue l'appel suivant n'obtiendra aucune
-- valeur, et devra la créer
local foo = r:ivm_get("cached_data")
if not foo then
foo = do_some_calcs() -- simulation de valeurs de retour
r:ivm_set("cached_data", foo) -- définition globale de la variable
end
r:puts("La donnée en cache est : ", foo)
end
r:htpassword(string [,algorithm [,cost]]) -- GénÚre un hash de mot de passe à partir d'une chaßne.
-- algorithm: 0 = APMD5 (défaut), 1 = SHA, 2 = BCRYPT, 3 = CRYPT.
-- cost: ne s'utilise qu'avec l'algorythme BCRYPT (défaut = 5).
r:mkdir(dir [,mode]) -- Crée un répertoire et définit son mode via le paramÚtre optionnel mode.
r:mkrdir(dir [,mode]) -- Crée des répertoires de maniÚre récursive et définit
-- leur mode via le paramĂštre optionnel mode.
r:rmdir(dir) -- Supprime un répertoire.
r:touch(file [,mtime]) -- DĂ©finit la date de modification d'un fichier Ă la date courante ou Ă
-- la valeur optionnelle mtime en msec.
r:get_direntries(dir) -- Renvoie une table contenant toutes les entrées de répertoires.
-- Renvoie un chemin sous forme éclatée en chemin, fichier, extension
function handle(r)
local dir = r.context_document_root
for _, f in ipairs(r:get_direntries(dir)) do
local info = r:stat(dir .. "/" .. f)
if info then
local mtime = os.date(fmt, info.mtime / 1000000)
local ftype = (info.filetype == 2) and "[dir] " or "[file]"
r:puts( ("%s %s %10i %s\n"):format(ftype, mtime, info.size, f) )
end
end
end
r.date_parse_rfc(string) -- InterprÚte une chaßne date/heure et renvoie l'équivalent en secondes depuis epoche.
r:getcookie(key) -- Obtient un cookie HTTP
r:setcookie(key, value, secure, expires) -- Définit un cookie HTTP, par exemple :
r:setcookie("foo", "bar and stuff", false, os.time() + 86400)
r:wsupgrade() -- Met à jour une connexion vers les WebSockets si possible (et si demandé) :
if r:wsupgrade() then -- si la mise Ă jour est possible :
r:wswrite("Bienvenue dans les websockets!") -- écrit quelque chose à l'intention du client
r:wsclose() -- Au revoir !
end
r:wsread() -- Lit un cadre de websocket depuis une connexion vers websocket mise Ă jour (voir ci-dessus) :
local line, isFinal = r:wsread() -- isFinal indique s'il s'agit du cadre final.
-- dans le cas contraire, on peut lire les cadres suivants
r:wswrite("Vous avez écrit : " .. line)
r:wswrite(line) -- écrit un cadre vers un client WebSocket :
r:wswrite("Bonjour le Monde !")
r:wsclose() -- ferme une requĂȘte WebSocket et l'achĂšve pour httpd :
if r:wsupgrade() then
r:wswrite("Ecrire quelque chose : ")
local line = r:wsread() or "nothing"
r:wswrite("Vous avez écrit : " .. line);
r:wswrite("Au revoir !")
r:wsclose()
end
-- 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")
Le paquet nommé apache2 est fourni avec (au minimum) le
contenu suivant :
mod_proxymod_authz_coreLes autres codes d'état HTTP ne sont pas encore implémentés.
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
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.
dbType, le premier paramĂštre de dbacquire, est
sensible Ă la casse.
Ses valeurs possibles sont mysql, pgsql,
freetds, odbc, sqlite2,
sqlite3, oracle ou mod_dbd.
L'exemple suivant montre comment se connecter à une base de données et extraire des informations d'une table :
function handle(r)
-- connexion à la base de données
local database, err = r:dbacquire("mysql", "server=localhost,user=someuser,pass=somepass,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 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()
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 local row = result(-1, true) -- Lit l'enregistrement suivant en utilisant les noms d'enregistrements comme index.
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
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
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.
| Description: | Branche une fonction fournisseur d'autorisation dans mod_authz_core
|
|---|---|
| Syntaxe: | LuaAuthzProvider provider_name /path/to/lua/script.lua function_name |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_lua |
| Compatibilité: | Disponible depuis la version 2.4.3 du serveur HTTP Apache |
Lorsqu'une fonction lua a été enregistrée en tant que fournisseur
d'autorisation, elle peut ĂȘtre appelĂ©e via la directive Require :
LuaRoot "/usr/local/apache2/lua" LuaAuthzProvider foo authz.lua authz_check_foo <Location "/"> Require foo johndoe </Location>
require "apache2"
function authz_check_foo(r, who)
if r.user ~= who then return apache2.AUTHZ_DENIED
return apache2.AUTHZ_GRANTED
end
| Description: | Configure le cache de code compilé. |
|---|---|
| Syntaxe: | LuaCodeCache stat|forever|never |
| Défaut: | LuaCodeCache stat |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Cette directive permet de définir le comportement du cache de code en mémoire. La valeur par défaut est stat ; dans ce cas, le script du niveau le plus haut (et pas les scripts inclus) est vérifié à chaque fois que ce fichier est nécessaire, et est rechargé si la date de modification est plus récente que celle du script déjà chargé. Les autres valeurs permettent respectivement de garder le fichier en cache perpétuellement (forever - jamais vérifié ni remplacé), ou de ne jamais le mettre en cache (never).
En général, les valeurs stat et forever sont utilisées pour un serveur en production, et les valeurs stat ou never pour un serveur en développement.
LuaCodeCache stat LuaCodeCache forever LuaCodeCache never
| Description: | Fournit un point d'entrĂ©e pour la phase access_checker du traitement de la requĂȘte |
|---|---|
| Syntaxe: | LuaHookAccessChecker /chemin/vers/lua/script.lua hook_function_name [early|late] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
| Compatibilité: | Le troisiÚme argument optionnel est disponible depuis la version 2.3.15 du serveur HTTP Apache. |
Ajoute votre fonction d'accroche à la phase access_checker. Une fonction d'accroche access checker renvoie en général OK, DECLINED, ou HTTP_FORBIDDEN.
Les arguments optionnels "early" ou "late" permettent de contrÎler le moment auquel ce script s'exécute par rapport aux autres modules.
| Description: | Fournit un point d'entrĂ©e pour la phase auth_checker du traitement de la requĂȘte |
|---|---|
| Syntaxe: | LuaHookAuthChecker /chemin/vers/lua/script.lua hook_function_name [early|late] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
| Compatibilité: | Le troisiÚme argument optionnel est disponible depuis la version 2.3.15 du serveur HTTP Apache. |
Invoque une fonction lua au cours de la phase auth_checker du traitement de la requĂȘte. Cette directive peut s'utiliser pour implĂ©menter une vĂ©rification arbitraire de l'authentification et de l'autorisation. Voici un exemple trĂšs simple :
require 'apache2'
-- fonction d'accroche authcheck fictive
-- Si la requĂȘte ne contient aucune donnĂ©e d'authentification, l'en-tĂȘte
-- de la réponse est défini et un code 401 est renvoyé afin de demander au
-- navigateur d'effectuer une authentification basique. Si la requĂȘte
-- comporte des données d'authentification, elles ne sont pas vraiment
-- consultées, mais on admet la prise en compte de l'utilisateur 'foo' et
-- on la valide. On vérifie ensuite si l'utilisateur est bien 'foo' et on
-- accepte la requĂȘte.
function authcheck_hook(r)
-- recherche des informations d'authentification
auth = r.headers_in['Authorization']
if auth ~= nil then
-- définition d'un utilisateur par défaut
r.user = 'foo'
end
if r.user == nil then
r:debug("authcheck: user is nil, returning 401")
r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
return 401
elseif r.user == "foo" then
r:debug('user foo: OK')
else
r:debug("authcheck: user='" .. r.user .. "'")
r.err_headers_out['WWW-Authenticate'] = 'Basic realm="WallyWorld"'
return 401
end
return apache2.OK
end
Les arguments optionnels "early" ou "late" permettent de contrÎler le moment auquel ce script s'exécute par rapport aux autres modules.
| Description: | Fournit un point d'entrĂ©e pour la phase check_user_id du traitement de la requĂȘte |
|---|---|
| Syntaxe: | LuaHookCheckUserID /chemin/vers/lua/script.lua hook_function_name [early|late] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
| Compatibilité: | Le troisiÚme argument optionnel est disponible depuis la version 2.3.15 du serveur HTTP Apache. |
...
Les arguments optionnels "early" ou "late" permettent de contrÎler le moment auquel ce script s'exécute par rapport aux autres modules.
| Description: | Fournit un point d'entrĂ©e pour la phase de correction du traitement de la requĂȘte |
|---|---|
| Syntaxe: | LuaHookFixups /chemin/vers/lua/script.lua hook_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Idem LuaHookTranslateName, mais s'exécute durant la phase de correction.
| Description: | Fournit un point d'entrĂ©e pour la phase insert_filter du traitement de la requĂȘte |
|---|---|
| Syntaxe: | LuaHookInsertFilter /chemin/vers/lua/script.lua hook_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Non encore implémenté
| Description: | Permet une insertion dans la phase de journalisation du traitement d'une requĂȘte |
|---|---|
| Syntaxe: | LuaHookLog /path/to/lua/script.lua log_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Ce dispositif d'insertion simple permet d'exécuter une fonction
lorsque httpd entre dans la phase de journalisation du traitement
d'une requĂȘte. Vous pouvez ainsi ajouter des donnĂ©es Ă vos propres
entrées de journalisation, manipuler les entrées du journal standard
avant leur enregistrement ou empĂȘcher l'enregistrement d'une entrĂ©e
dans le journal. Pour empĂȘcher l'enregistrement normal des entrĂ©es
du journal, renvoyez simplement apache2.DONE dans votre
gestionnaire de journalisation, ou au contraire, renvoyez
apache2.OK pour que httpd effectue une journalisation
normale.
Exemple :
LuaHookLog "/path/to/script.lua" logger
-- /path/to/script.lua --
function logger(r)
-- on joue Ă pile ou face :
-- Si on obtient 1, on écrit dans notre propre journal Lua et on dit
-- à httpd de ne pas enregistrer d'entrée dans le journal standard..
-- Si on obtient 2, on nettoie un peu les données avant que httpd ne
-- les enregistre dans le journal standard.
if math.random(1,2) == 1 then
-- On effectue notre propre journalisation et le journal
-- standard n'est pas alimenté
local f = io.open("/foo/secret.log", "a")
if f then
f:write("Quelque chose de secret est arrivé à " .. r.uri .. "\n")
f:close()
end
return apache2.DONE -- On dit Ă httpd de ne rien enregistrer
--dans le journal standard
else
r.uri = r.uri:gsub("somesecretstuff", "") -- nettoie les données
return apache2.OK -- et httpd doit alors les enregistrer.
end
end
| Description: | Fournit un point d'entrĂ©e pour la phase map_to_storage du traitement de la requĂȘte |
|---|---|
| Syntaxe: | LuaHookMapToStorage /chemin/vers/lua/script.lua hook_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Identique Ă la directive
LuaHookTranslateName, mais s'exécute à la phase
map-to-storage du traitement de la requĂȘte. Les modules comme
mod_cache agissent pendant cette phase, ce qui permet de
présenter un exemple intéressant de ce que l'on peut faire ici :
LuaHookMapToStorage "/path/to/lua/script.lua" check_cache
require"apache2"
cached_files = {}
function read_file(filename)
local input = io.open(filename, "r")
if input then
local data = input:read("*a")
cached_files[filename] = data
file = cached_files[filename]
input:close()
end
return cached_files[filename]
end
function check_cache(r)
if r.filename:match("%.png$") then -- Ne concerne que les fichiers PNG
local file = cached_files[r.filename] -- Vérifie les entrées du cache
if not file then
file = read_file(r.filename) -- Lit le fichier vers le cache
end
if file then -- Si le fichier existe, on l'envoie
r.status = 200
r:write(file)
r:info(("%s a été envoyé au client depuis le cache"):format(r.filename))
return apache2.DONE -- cout-circuite le gestionnaire par défaut des fichiers PNG
end
end
return apache2.DECLINED -- Si nous n'avons rien eu Ă faire, nous laissons les autres s'en charger
end
| Description: | Fournit un point d'entrĂ©e pour la phase de prĂ©-traduction du traitement d'une requĂȘte |
|---|---|
| Syntaxe: | LuaHookPreTranslate /path/to/lua/script.lua hook_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Identique Ă LuaHookTranslateName, mais s'exĂ©cute au cours de la phase de prĂ©-traduction oĂč les pourcentages du chemin de l'URI ne sont pas encore dĂ©codĂ©s.
| Description: | Fournit un point d'entrĂ©e Ă la phase du nom de traduction du traitement de la requĂȘte |
|---|---|
| Syntaxe: | LuaHookTranslateName /chemin/vers/lua/script.lua nom_fonction_hook [early|late] |
| Contexte: | configuration globale, serveur virtuel |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
| Compatibilité: | Le troisiÚme argument optionnel est disponible depuis la version 2.3.15 du serveur HTTP Apache. |
Cette directive permet d'ajouter un point d'entrĂ©e (Ă APR_HOOK_MIDDLE) Ă la phase du nom de traduction du traitement de la requĂȘte. La fonction hook accepte un seul argument, le request_rec, et doit renvoyer un code d'Ă©tat qui est soit un code d'erreur HTTP, ou une constante dĂ©finie dans le module apache2 : apache2.OK, apache2.DECLINED, ou apache2.DONE.
Pour ceux qui ne sont pas familiers avec les points d'entrĂ©e (hook), en gros, chaque hook sera invoquĂ© jusqu'Ă ce que l'un d'entre eux renvoie apache2.OK. Si un hook n'effectuer pas la traduction, il doit juste renvoyer apache2.DECLINED. Si le traitement de la requĂȘte doit ĂȘtre interrompu, la valeur renvoyĂ©e doit ĂȘtre apache2.DONE.
Exemple :
# httpd.conf LuaHookTranslateName "/scripts/conf/hooks.lua" silly_mapper
-- /scripts/conf/hooks.lua --
require "apache2"
function silly_mapper(r)
if r.uri == "/" then
r.filename = "/var/www/home.lua"
return apache2.OK
else
return apache2.DECLINED
end
end
Cette directive ne peut ĂȘtre
utilisée ni à l'intérieur d'une section <Directory> ou <Files>, ni dans un fichier htaccess.
Les arguments optionnels "early" ou "late" permettent de contrÎler le moment auquel ce script s'exécute par rapport aux autres modules.
| Description: | Fournit un point d'entrĂ©e pour la phase type_checker du traitement de la requĂȘte |
|---|---|
| Syntaxe: | LuaHookTypeChecker /chemin/vers/lua/script.lua hook_function_name |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Cette directive fournit un point d'entrĂ©e pour la phase type_checker du traitement de la requĂȘte. Cette phase correspond au moment oĂč la requĂȘte se voit assigner un type et un gestionnaire de contenu, et peut donc ĂȘtre utilisĂ©e pour modifier le type et le gestionnaire en fonction de l'entrĂ©e :
LuaHookTypeChecker "/path/to/lua/script.lua" type_checker
function type_checker(r)
if r.uri:match("%.to_gif$") then -- foo.png.to_gif convient
r.content_type = "image/gif" -- affectation du type image/gif
r.handler = "gifWizard" -- force le traitement de la requĂȘte par le module gifWizard
r.filename = r.uri:gsub("%.to_gif$", "") -- corrige le nom du fichier demandé
return apache2.OK
end
return apache2.DECLINED
end
| Description: | ContrÎle la maniÚre dont les sections de configuration parentes sont fusionnées dans les enfants |
|---|---|
| Syntaxe: | LuaInherit none|parent-first|parent-last |
| Défaut: | LuaInherit parent-first |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
| Compatibilité: | Versions 2.4.0 et supérieures |
Par défaut, si des directives LuaHook* se trouvent dans des sections de configuration Directory ou Location qui se chevauchent, les scripts définis dans les sections les plus spécifiques s'exécutent aprÚs ceux définis dans les sections plus génériques (LuaInherit parent-first). Vous pouvez inverser cet ordre, ou faire en sorte que le contexte parent ne s'applique pas du tout.
Jusqu'aux versions 2.3.x, le comportement par défaut consistait à ignorer les directives LuaHook* situées dans les sections de configuration parentes.
| Description: | Fournit une fonction Lua pour le filtrage en entrée |
|---|---|
| Syntaxe: | LuaInputFilter filter_name /path/to/lua/script.lua function_name |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_lua |
| Compatibilité: | Disponible depuis la version 2.4.5 du serveur HTTP Apache |
Cette directive permet d'ajouter un filtre en entrée sous la forme
d'une fonction Lua. A l'instar des filtres en sorties, les filtres en
entrée fonctionnent comme des sous-routines, intervenant dans un premier
temps avant l'envoi du contenu des tampons, puis chaque fois qu'un
paquet de donnĂ©es doit ĂȘtre transmis Ă la chaĂźne, et Ă©ventuellement
produisant toute donnée à ajouter aux données en entrée. La variable
globale bucket contient les paquets de données tels qu'ils
sont transmis au script Lua :
LuaInputFilter myInputFilter "/www/filter.lua" input_filter <Files "*.lua"> SetInputFilter myInputFilter </Files>
--[[
Exemple de filtre en entrée qui convertit toutes les données POST en
majuscules.
]]--
function input_filter(r)
print("luaInputFilter called") -- pour débogage
coroutine.yield() -- attend des paquets de données
while bucket do -- Pour chaque paquet, faire ...
local output = string.upper(bucket) -- Convertit toutes les données POST en majuscules
coroutine.yield(output) -- Envoie les données traitées à la chaßne de filtrage
end
-- plus aucune donnée à traiter.
coroutine.yield("&filterSignature=1234") -- Ajoute une signature Ă la fin
end
Le filtre en entrée peut interdire ou sauter un filtre s'il est considéré comme indésirable :
function input_filter(r)
if not good then
return -- EmpĂȘche tout simplement le filtrage et transmet le contenu original
end
coroutine.yield() -- attend des paquets de données
... -- insert les filtres ici
end
Voir "Modification de contenu avec les filtres Lua" pour plus de détails.
| Description: | Met en correspondance un chemin avec un gestionnaire lua |
|---|---|
| Syntaxe: | LuaMapHandler modele-uri /chemin/vers/lua/script.lua
[nom-fonction] |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Cette directive permet de faire correspondre un modÚle d'uri avec une fonction de gestionnaire située dans un fichier spécifique. Elle utilise les expressions rationnelles PCRE pour mettre en correspondance l'uri, et supporte les groupes de correspondance d'interpolation dans le chemin du fichier et le nom de la fonction. Prenez garde aux problÚmes de sécurité en écrivant vos expressions rationnelles.
LuaMapHandler "/(\w+)/(\w+)" "/scripts/$1.lua" "handle_$2"
Cette directive va faire correspondre des uri comme /photos/show?id=9 au fichier /scripts/photos.lua, et invoquera la fonction de gestionnaire handle_show au niveau de la vm lua aprĂšs chargement de ce fichier.
LuaMapHandler "/bingo" "/scripts/wombat.lua"
Cette directive invoquera la fonction "handle" qui est la valeur par défaut si aucun nom de fonction spécifique n'est spécifié.
| Description: | Fournit une fonction Lua pour le filtrage de contenu en sortie |
|---|---|
| Syntaxe: | LuaOutputFilter filter_name /path/to/lua/script.lua function_name |
| Contexte: | configuration globale |
| Statut: | Extension |
| Module: | mod_lua |
| Compatibilité: | Disponible à partir de la version 2.4.5 du serveur HTTP Apache |
>Cette directive permet d'ajouter un filtre en sortie sous la forme
d'une fonction Lua. A l'instar des filtres en sorties, les filtres en
entrée fonctionnent comme des sous-routines, intervenant dans un premier
temps avant l'envoi du contenu des tampons, puis chaque fois qu'un
paquet de donnĂ©es doit ĂȘtre transmis Ă la chaĂźne, et Ă©ventuellement
produisant toute donnée à ajouter aux données en sortie. La variable
globale bucket contient les paquets de données tels qu'ils
sont transmis au script Lua :
LuaOutputFilter myOutputFilter "/www/filter.lua" output_filter <Files "*.lua"> SetOutputFilter myOutputFilter </Files>
--[[
Exemple de filtre en sortie qui échappe toutes les entités HTML en
sortie
]]--
function output_filter(r)
coroutine.yield("(Handled by myOutputFilter)<br/>\n") -- Ajoute des données au début de la sortie,
-- puis attend des paquets de données à traiter
while bucket do -- Pour chaque paquet, faire ...
local output = r:escape_html(bucket) -- Echappe les données en sortie
coroutine.yield(output) -- Envoie les données traitées à la chaßne
end
-- plus aucune donnée à traiter.
end
Comme les filres en entrée, le filtre en sortie peut interdire ou sauter un filtre s'il est considéré comme indésirable :
function output_filter(r)
if not r.content_type:match("text/html") then
return -- EmpĂȘche tout simplement le filtrage et transmet le contenu original
end
coroutine.yield() -- attend des paquets de données
... -- insert les filtres ici
end
mod_filterLorsqu'on utilise un filtre Lua comme fournisseur sous-jacent via la
directive FilterProvider, le
filtrage ne fonctionnera que si filter-name est identique Ă
provider-name.
Voir "Modification de contenu avec les filtres Lua" pour plus de détails.
| Description: | Ajoute un répertoire au package.cpath de lua |
|---|---|
| Syntaxe: | LuaPackageCPath /chemin/vers/include/?.soa |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Cette directive permet d'ajouter un chemin à la liste des chemins de recherche des bibliothÚques partagées de lua. Ceci modifie le package.cpath dans les vms lua.
| Description: | Ajoute un répertoire au package.path de lua |
|---|---|
| Syntaxe: | LuaPackagePath /chemin/vers/include/?.lua |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Cette directive permet d'ajouter un chemin Ă la liste des chemins de recherche du module lua. Elle suit les mĂȘmes conventions que lua. Ceci modifie le package.path dans les vms lua.
LuaPackagePath "/scripts/lib/?.lua" LuaPackagePath "/scripts/lib/?/init.lua"
| Description: | Fournit un point d'entrĂ©e pour la gestion rapide du traitement de la requĂȘte |
|---|---|
| Syntaxe: | LuaQuickHandler /path/to/script.lua hook_function_name |
| Contexte: | configuration globale, serveur virtuel |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Cette phase s'exĂ©cute juste aprĂšs l'attribution de la requĂȘte Ă
un serveur virtuel, et permet d'effectuer certains traitements avant
le dĂ©roulement des autres phases, ou de servir une requĂȘte sans
avoir Ă la traduire, l'associer Ă un espace de stockage, etc...
Comme cette phase s'exécute avant toute autre, les directives telles
que <Location> ou
<Directory> ne
sont pas encore prises en compte, car Les URI n'ont pas encore été
entiÚrement interprétés.
Cette directive ne peut ĂȘtre
utilisée ni à l'intérieur d'une section <Directory> ou <Files>, ni dans un fichier htaccess.
| Description: | Spécifie le chemin de base pour la résolution des chemins
relatifs dans les directives de mod_lua |
|---|---|
| Syntaxe: | LuaRoot /chemin/vers/un/répertoire |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Cette directive permet de spécifier le chemin de base qui sera
utilisé pour évaluer tous les chemins relatifs dans mod_lua. En
l'absence de cette directive, les chemins relatifs sont résolus par
rapport au répertoire de travail courant, ce qui ne sera pas
toujours approprié pour un serveur.
| Description: | Une valeur parmi once, request, conn, thread -- la valeur par défaut est once |
|---|---|
| Syntaxe: | LuaScope once|request|conn|thread|server [min] [max] |
| Défaut: | LuaScope once |
| Contexte: | configuration globale, serveur virtuel, répertoire, .htaccess |
| Surcharges autorisées: | All |
| Statut: | Extension |
| Module: | mod_lua |
Cette directive permet de spécifier la durée de vie de l'interpréteur Lua qui sera utilisé dans ce "répertoire". La valeur par défaut est "once".
min et max permettent
de spécifier les nombres minimaux et maximaux d'états lua à stocker
dans la liste.En général, les portées thread et server
sont 2 Ă 3 fois plus rapides que les autres, car elles n'ont pas besoin
de rĂ©gĂ©nĂ©rer de nouveaux Ă©tats Lua Ă chaque requĂȘte (comme c'est le
cas avec le MPM event, oĂč mĂȘme les connexions persistantes utilisent un
nouveau thread pour chaque requĂȘte). Si vous pensez que vos scripts
n'auront pas de problÚme s'il réutilisent un état, alors les portées
thread ou server doivent ĂȘtre utilisĂ©es car
elles présenteront de meilleures performances. Alors que la portée
thread fournira les réponses les plus rapides, la portée
server utilisera moins de mémoire car les états sont
rassemblés dans des jeux, permettant par exemple à 1000 threads de
partager 100 états Lua, ne nécessitant ainsi que 10% de la mémoire
requise par la portée thread.