mod_lua.xml.fr revision 2f9366949536a4aeb4aba916b771b94681e161d2
<?xml version="1.0"?>
<!-- English Revision: 1355934:1367082 (outdated) -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<modulesynopsis metafile="mod_lua.xml.meta">
<name>mod_lua</name>
<description>Fournit des points d'entrée Lua dans différentes parties du
traitement des requêtes httpd</description>
<status>Experimental</status>
<identifier>lua_module</identifier>
<compatibility>versions 2.3 et supérieures</compatibility>
<summary>
<p>Ce module permet d'ajouter au serveur des extensions sous forme de
scripts écrits dans le langage de programmation Lua.
<module>mod_lua</module> 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.</p>
<p>Vous trouverez davantage d'informations à propos du langage de
programmation Lua sur <a href="http://www.lua.org/">le site web de
Lua</a>.</p>
<note><code>mod_lua</code> est encore au stade expérimental. Son mode
d'utilisation et son comportement pourront changer à tout moment jusqu'à
ce qu'il passe au stade stable, et ce même entre deux versions stables
2.4.x. N'oublez pas de consulter le fichier CHANGES avant toute mise à
jour.</note>
</summary>
<section id="basicconf"><title>Configuration de base</title>
<p>La directive de base pour le chargement du module est</p>
<highlight language="config">
LoadModule lua_module modules/mod_lua.so
</highlight>
<p>
<code>mod_lua</code> fournit un gestionnaire nommé
<code>lua-script</code> qui peut être utilisé avec une directive
<code>AddHandler</code> :</p>
<highlight language="config">
AddHandler lua-script .lua
</highlight>
<p>
Ceci aura pour effet de faire traiter les requêtes pour les fichiers
dont l'extension est <code>.lua</code> par <code>mod_lua</code> en
invoquant cette fonction de <code>gestion</code> de fichier.
</p>
<p>Pour plus de détails, voir la directive
<directive>LuaMapHandler</directive>.
</p>
</section>
<section id="writinghandlers"><title>Ecrire des gestionnaires</title>
<p>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. <module>mod_proxy</module>, <module>mod_cgi</module> et
<module>mod_status</module> sont des exemples de modules comportant un
gestionnaire.</p>
<p><code>mod_lua</code> 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 :</p>
<highlight language="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: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
</highlight>
<p>
Ce gestionnaire se contente d'afficher les arguments codés d'un uri ou
d'un formulaire dans un page au format texte.
</p>
<p>
Cela signifie que vous pouvez (et êtes encouragé à) avoir plusieurs
gestionnaires (ou points d'entrée, ou filtres) dans le même script.
</p>
</section>
<section id="writingauthzproviders">
<title>Ecriture de fournisseurs d'autorisation</title>
<p><module>mod_authz_core</module> fournit une interface d'autorisation
de haut niveau bien plus facile à utiliser que dans les hooks
correspondants. Le premier argument de la directive <directive
module="mod_authz_core">Require</directive> permet de spécifier le
fournisseur d'autorisation à utiliser. Pour chaque directive <directive
module="mod_authz_core">Require</directive>,
<module>mod_authz_core</module> 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.</p>
<p>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
déclancher le processus d'authentification et un deuxième appel du
fournisseur authz.</p>
<p>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 :</p>
<highlight language="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
</highlight>
<p>La configuration suivante enregistre cette fonction en tant que
fournisseur <code>foo</code>, et la configure por l'URL <code>/</code> :</p>
<highlight language="config">
LuaAuthzProvider foo authz_provider.lua authz_check_foo
<Location />
Require foo 10.1.2.3 john_doe
</Location>
</highlight>
</section>
<section id="writinghooks"><title>Ecriture de fonctions d'accroche
(hooks)</title>
<p>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. Il existe aussi des accroches à usage
général qui s'exécutent simplement à des moments opportuns du cycle
de vie de la requête.</p>
<p>Les fonctions d'accroche acceptent l'objet de la requête comme seul
et unique argument. 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,
<highlight language="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
return apache2.OK
end
-- on ne gère pas cette URL et on donne sa chance à un autre module
return apache2.DECLINED
end
</highlight>
<highlight language="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: actuellement, il est impossible de prévoir si cette action
s'exécute 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
</highlight>
</section>
<section id="datastructures"><title>Structures de données</title>
<dl>
<dt>request_rec</dt>
<dd>
<p>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 (voir httpd.h en
attendant que cette documentation soit plus complète), 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).</p>
<table border="1">
<tr>
<th><strong>Nom</strong></th>
<th><strong>Type Lua</strong></th>
<th><strong>Modifiable</strong></th>
</tr>
<tr>
<td><code>ap_auth_type</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>args</code></td>
<td>string</td>
<td>oui</td>
</tr>
<tr>
<td><code>assbackwards</code></td>
<td>boolean</td>
<td>non</td>
</tr>
<tr>
<td><code>canonical_filename</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>content_encoding</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>content_type</code></td>
<td>string</td>
<td>oui</td>
</tr>
<tr>
<td><code>context_prefix</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>context_document_root</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>document_root</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>err_headers_out</code></td>
<td>table</td>
<td>non</td>
</tr>
<tr>
<td><code>filename</code></td>
<td>string</td>
<td>oui</td>
</tr>
<tr>
<td><code>handler</code></td>
<td>string</td>
<td>oui</td>
</tr>
<tr>
<td><code>headers_in</code></td>
<td>table</td>
<td>oui</td>
</tr>
<tr>
<td><code>headers_out</code></td>
<td>table</td>
<td>oui</td>
</tr>
<tr>
<td><code>hostname</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>log_id</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>method</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>notes</code></td>
<td>table</td>
<td>oui</td>
</tr>
<tr>
<td><code>path_info</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>protocol</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>proxyreq</code></td>
<td>string</td>
<td>oui</td>
</tr>
<tr>
<td><code>range</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>subprocess_env</code></td>
<td>table</td>
<td>oui</td>
</tr>
<tr>
<td><code>status</code></td>
<td>number</td>
<td>oui</td>
</tr>
<tr>
<td><code>the_request</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>unparsed_uri</code></td>
<td>string</td>
<td>non</td>
</tr>
<tr>
<td><code>uri</code></td>
<td>string</td>
<td>oui</td>
</tr>
<tr>
<td><code>user</code></td>
<td>string</td>
<td>oui</td>
</tr>
<tr>
<td><code>useragent_ip</code></td>
<td>string</td>
<td>non</td>
</tr>
</table>
<p>La structure request_rec possède (au minimum) les méthodes
suivantes :</p>
<highlight language="lua">
r:addoutputfilter(name|function) -- ajoute un filtre en sortie
</highlight>
<highlight language="lua">
r:parseargs() -- renvoie une table Lua contenant la chaîne
d'arguments de la requête
</highlight>
<highlight language="lua">
r:parsebody() -- interprète toutes données POST de la requête et
les renvoie sous forme de table Lua
</highlight>
<highlight language="lua">
r:puts("bonjour", " le monde", "!") -- affichage dans le corps de la réponse
</highlight>
<highlight language="lua">
r:write("une simple chaîne") -- affichage dans le
corps de la réponse
</highlight>
</dd>
</dl>
</section>
<section id="logging"><title>Fonctions de journalisation</title>
<highlight language="lua">
-- exemples de messages de journalisation
r:trace1("Ceci est un message de journalisation de niveau
trace") -- les niveaux valides vont de trace1 à trace8 <br />
r:debug("Ceci est un message de journalisation de niveau debug")<br />
r:info("Ceci est un message de journalisation de niveau info")<br />
r:notice("Ceci est un message de journalisation de niveau notice")<br />
r:warn("Ceci est un message de journalisation de niveau warn")<br />
r:err("Ceci est un message de journalisation de niveau err")<br />
r:alert("Ceci est un message de journalisation de niveau alert")<br />
r:crit("Ceci est un message de journalisation de niveau crit")<br />
r:emerg("Ceci est un message de journalisation de niveau emerg")<br />
</highlight>
</section>
<section id="apache2"><title>Paquet apache2</title>
<p>Le paquet nommé <code>apache2</code> est fourni avec (au minimum) le
contenu suivant :</p>
<dl>
<dd>Constante interne OK. Les gestionnaires renverront cette valeur
s'ils ont traité la requête.</dd>
<dd>Constante interne DECLINED. Les gestionnaires renverront cette
valeur s'ils n'ont pas l'intention de traiter la requête.</dd>
<dd>Constante interne DONE.</dd>
<dd>Chaîne contenant la version du serveur HTTP Apache</dd>
<dd>Code d'état HTTP</dd>
<dt>apache2.PROXYREQ_NONE, apache2.PROXYREQ_PROXY, apache2.PROXYREQ_REVERSE, apache2.PROXYREQ_RESPONSE</dt>
<dd>Constantes internes utilisées par <module>mod_proxy</module></dd>
</dl>
<p>Les autres codes d'état HTTP ne sont pas encore implémentés.</p>
</section>
<directivesynopsis>
<name>LuaRoot</name>
<description>Spécifie le chemin de base pour la résolution des chemins
relatifs dans les directives de mod_lua</description>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p>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.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaScope</name>
<description>Une valeur parmi once, request, conn, server -- la valeur
par défaut est once</description>
<syntax>LuaScope once|request|conn|server [max|min max]</syntax>
<default>LuaScope once</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p>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".</p>
<dl>
<dt>once:</dt> <dd>utilise l'interpréteur une fois.</dd>
<dt>request:</dt> <dd>utilise l'interpréteur pour traiter tout ce
qui est basé sur le même fichier dans la requête, et qui se trouve
aussi dans la portée de la requête.</dd>
<dt>conn:</dt> <dd>idem request, mais attaché à connection_rec</dd>
<dt>server:</dt> <dd>Le comportement est ici différent, car la
portée du serveur présente une durée de vie assez longue, et
plusieurs threads vont partager le même server_rec. Pour gérer tout
ceci, les interpréteurs sont stockés dans une liste de ressources
apr. Les arguments min et max ont été prévus pour spécifier une
taille de jeu, mais sont inutilisés pour le moment.</dd>
</dl>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaMapHandler</name>
<description>Met en correspondance un chemin avec un gestionnaire lua</description>
[nom-fonction]</syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p>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.</p>
<example><title>Exemples :</title>
<highlight language="config">
LuaMapHandler /(\w+)/(\w+) /scripts/$1.lua handle_$2
</highlight>
</example>
<p>Cette directive va faire correspondre des uri comme
fonction de gestionnaire handle_show au niveau de la vm lua
après chargement de ce fichier.</p>
<highlight language="config">
LuaMapHandler /bingo /scripts/wombat.lua
</highlight>
<p>Cette directive invoquera la fonction "handle" qui est la
valeur par défaut si aucun nom de fonction spécifique n'est
spécifié.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaPackagePath</name>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage><p>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.</p>
<example><title>Exemples :</title>
<highlight language="config">
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaPackageCPath</name>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p>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.</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaCodeCache</name>
<description>Configure le cache de code compilé.</description>
<syntax>LuaCodeCache stat|forever|never</syntax>
<default>LuaCodeCache stat</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage><p>
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).</p>
<p>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.</p>
<example><title>Exemples :</title>
<highlight language="config">
LuaCodeCache stat
LuaCodeCache forever
LuaCodeCache never
</highlight>
</example>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaHookTranslateName</name>
<description>Fournit un point d'entrée à la phase du nom de
traduction du traitement de la requête</description>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context>
</contextlist>
<override>All</override>
<compatibility>Le troisième argument optionnel est disponible depuis la
version 2.3.15 du serveur HTTP Apache.</compatibility>
<usage><p>
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,
<p>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.</p>
<p>Exemple :</p>
<highlight language="config">
</highlight>
<highlight language="lua">
require "apache2"
function silly_mapper(r)
if r.uri == "/" then
return apache2.OK
else
return apache2.DECLINED
end
end
</highlight>
<note><title>Contexte</title><p>Cette directive ne peut être
utilisée ni à l'intérieur d'une section <directive type="section"
module="core">Directory</directive> ou <directive type="section"
module="core">Files</directive>, ni dans un fichier htaccess.</p></note>
<note><title>Ordonnancement</title><p>Les arguments optionnels
"early" ou "late" permettent de contrôler le moment auquel ce script
s'exécute par rapport aux autres modules.</p></note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaHookFixups</name>
<description>Fournit un point d'entrée pour la phase de correction du
traitement de la requête</description>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage>
<p>
Idem LuaHookTranslateName, mais s'exécute durant la phase de
correction.
</p>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaHookMapToStorage</name>
<description>Fournit un point d'entrée pour la phase map_to_storage du
traitement de la requête</description>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage><p>...</p></usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaHookCheckUserID</name>
<description>Fournit un point d'entrée pour la phase check_user_id du
traitement de la requête</description>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<compatibility>Le troisième argument optionnel est disponible depuis la
version 2.3.15 du serveur HTTP Apache.</compatibility>
<usage><p>...</p>
<note><title>Ordonnancement</title><p>Les arguments optionnels
"early" ou "late" permettent de contrôler le moment auquel ce script
s'exécute par rapport aux autres modules.</p></note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaHookTypeChecker</name>
<description>Fournit un point d'entrée pour la phase type_checker du
traitement de la requête</description>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage><p>...</p></usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaHookAuthChecker</name>
<description>Fournit un point d'entrée pour la phase auth_checker du
traitement de la requête</description>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<compatibility>Le troisième argument optionnel est disponible depuis la
version 2.3.15 du serveur HTTP Apache.</compatibility>
<usage>
<p>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 :
</p>
<highlight language="lua">
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
</highlight>
<note><title>Ordonnancement</title><p>Les arguments optionnels
"early" ou "late" permettent de contrôler le moment auquel ce script
s'exécute par rapport aux autres modules.</p></note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaHookAccessChecker</name>
<description>Fournit un point d'entrée pour la phase access_checker du
traitement de la requête</description>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<compatibility>Le troisième argument optionnel est disponible depuis la
version 2.3.15 du serveur HTTP Apache.</compatibility>
<usage>
<p>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.</p>
<note><title>Ordonnancement</title><p>Les arguments optionnels
"early" ou "late" permettent de contrôler le moment auquel ce script
s'exécute par rapport aux autres modules.</p></note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaHookInsertFilter</name>
<description>Fournit un point d'entrée pour la phase insert_filter du
traitement de la requête</description>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage><p>Non encore implémenté</p></usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaInherit</name>
<description>Contrôle la manière dont les sections de configuration
parentes sont fusionnées dans les enfants</description>
<syntax>LuaInherit none|parent-first|parent-last</syntax>
<default>LuaInherit parent-first</default>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<compatibility>Versions 2.4.0 et supérieures</compatibility>
<usage><p>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
<em>après</em> 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.</p>
<p>Jusqu'aux versions 2.3.x, le comportement par défaut consistait à
ignorer les directives LuaHook* situées dans les sections de
configuration parentes.</p></usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaQuickHandler</name>
<description>Fournit un point d'entrée pour la gestion rapide du
traitement de la requête</description>
<syntax></syntax>
<contextlist><context>server config</context><context>virtual host</context>
<context>directory</context><context>.htaccess</context>
</contextlist>
<override>All</override>
<usage><p>...</p>
<note><title>Contexte</title><p>Cette directive ne peut être
utilisée ni à l'intérieur d'une section <directive type="section"
module="core">Directory</directive> ou <directive type="section"
module="core">Files</directive>, ni dans un fichier htaccess.</p></note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>LuaAuthzProvider</name>
<description>Branche une fonction fournisseur d'autorisation dans <module>mod_authz_core</module>
</description>
<contextlist><context>server config</context> </contextlist>
<compatibility>Disponible depuis la version 2.5.0 du serveur HTTP Apache</compatibility>
<usage>
<p>Lorsqu'une fonction lua a été enregistrée en tant que fournisseur
d'autorisation, elle peut être appelée via la directive <directive
module="mod_authz_core">Require</directive> :</p>
<example>
<highlight language="config">
LuaAuthzProvider foo authz.lua authz_check_foo
<Location />
Require foo bar
</Location>
</highlight>
</example>
</usage>
</directivesynopsis>
</modulesynopsis>