Serveur Apache HTTP Version 2.5
Description: | Gestion des connexions à une base de données SQL |
---|---|
Statut: | Extension |
Identificateur de Module: | dbd_module |
Fichier Source: | mod_dbd.c |
Le module mod_dbd
gère les connexions
à une base de données SQL via APR. Il permet
aux modules qui requièrent des fonctions liées aux bases de données
SQL de se connecter à une base de données à la demande, et s'efforce
de conférer aux bases de données une efficacité et une
évolutivité optimales pour les MPMs threadés ou non threadés. Pour
plus de détails, voir le site web APR,
ainsi que cette vue d'ensemble de l'environnement de
développement d'Apache DBD par son développeur initial.
Ce module gère de manière optimisée en fonction de la plate-forme
les connexions aux bases de données. Sur les plates-formes non
threadées, il maintient une connexion persistente à la manière d'un
LAMP classique (Linux, Apache, Mysql, Perl/PHP/Python). Sur les
plates-formes threadées, il maintient un groupe de
connexions à la fois plus évolutif et plus efficace, comme
décrit dans cet
article d'ApacheTutor. Notez que mod_dbd
remplace les modules présentés dans cet article.
mod_dbd
exporte cinq fonctions que d'autres
modules pourront utiliser. L'API se présente comme suit :
typedef struct { apr_dbd_t *handle; apr_dbd_driver_t *driver; apr_hash_t *prepared; } ap_dbd_t; /* Fonctions exportées pour accéder à la base de données */ /* ouvre une connexion qui DEVRA être explicitement fermée. * Renvoie NULL en cas d'erreur */ AP_DECLARE(ap_dbd_t*) ap_dbd_open(apr_pool_t*, server_rec*); /* ferme une connexion ouverte avec ap_dbd_open */ AP_DECLARE(void) ap_dbd_close(server_rec*, ap_dbd_t*); /* acquiert une connexion qui aura la durée de vie de la requête et qui * NE DEVRA PAS être explicitement fermée. Renvoie NULL en cas * d'erreur. C'est la fonction recommandée pour la plupart des * applications. */ AP_DECLARE(ap_dbd_t*) ap_dbd_acquire(request_rec*); /* acquiert une connexion qui aura la durée de vie d'une connexion et * qui NE DEVRA PAS être explicitement fermée. Renvoie NULL en cas * d'erreur. */ AP_DECLARE(ap_dbd_t*) ap_dbd_cacquire(conn_rec*); /* Prépare une requête qu'un module client pourra utiliser */ AP_DECLARE(void) ap_dbd_prepare(server_rec*, const char*, const char*); /* Exporte aussi ces fonctions à titre optionnel mour les modules qui * péfèreraient les utiliser */ APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_open, (apr_pool_t*, server_rec*)); APR_DECLARE_OPTIONAL_FN(void, ap_dbd_close, (server_rec*, ap_dbd_t*)); APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_acquire, (request_rec*)); APR_DECLARE_OPTIONAL_FN(ap_dbd_t*, ap_dbd_cacquire, (conn_rec*)); APR_DECLARE_OPTIONAL_FN(void, ap_dbd_prepare, (server_rec*, const char*, const char*));
mod_dbd
supporte les requêtes SQL préparées pour
le compte des modules qui pourraient les utiliser. Chaque requête
préparée doit posséder un nom (étiquette), et est stockée dans un
condensé (hash) : les condensés sont du type
apr_dbd_prepared_t
et s'utilisent dans toute requête
SQL ou commande select préparée par apr_dbd.
Il est du ressort des modules utilisateurs de dbd d'utiliser les
requêtes préparées et de préciser quelles requêtes doivent être
spécifiées dans httpd.conf, ou de fournir leurs propres directives
et d'utiliser ap_dbd_prepare
.
reconnect
à 0 dans la chaîne de connexion, afin
d'éviter des erreurs provoquées par un client MySQL qui se
reconnecterait sans réinitialiser correctement les requêtes
préparées. Si reconnect
est défini à 1, toute
connexion défectueuse sera sensée être réparée, mais comme
mod_dbd n'en est pas informé, les requêtes préparées seront
invalidées.
Toute application web impliquant une base de données doit se protéger elle-même contre les attaques de type injection SQL. Dans la plupart des cas Apache DBD est sûr, car les applications utilisent des requêtes préparées, et les entrées non sûres ne seront utilisées qu'à titre de données. Bien entendu, si vous l'utilisez via un module tiers, vous devez être au fait des précautions à prendre.
Cependant, le pilote FreeTDS est non sûr de par sa nature même. Comme la bibliothèque sous-jacente ne supporte pas les requêtes préparées, le pilote en effectue une émulation, et les entrées non sûres sont fusionnées avec la requête SQL.
Il peut être sécurisé en décontaminant toutes les
entrées : un processus inspiré de la recherche de contaminations de
Perl (NdT : taint checking
). Chaque entrée est comparée
à une expression rationnelle, et
seules les entrées qui correspondent sont utilisées, en accord avec
le raccourci Perl :
$untrusted =~ /([a-z]+)/;
$trusted = $1;
Pour utiliser ceci, les expressions rationnelles de décontamination doivent être incluses dans les requêtes préparées. L'expression rationnelle doit se situer immédiatement après le caractère % dans la requête préparée, et doit être entourée d'accolades {}. Par exemple, si votre application attend une entrée alphanumérique, vous pouvez utiliser :
"SELECT foo FROM bar WHERE input = %s"
avec d'autres pilotes, et ne risquer au pire qu'une requête en échec. Mais avec FreeTDS, vous devez utiliser :
"SELECT foo FROM bar WHERE input = %{([A-Za-z0-9]+)}s"
tout ce qui ne correspond pas à l'expression rationnelle est alors rejeté, et la requête est ainsi désormais sûre.
Alternativement, vous pouvez utiliser le pilote ODBC tiers, qui offre la sécurité des requêtes préparées authentiques.
Description: | Durée de vie des connexions inactives |
---|---|
Syntaxe: | DBDExptime durée en secondes |
Défaut: | DBDExptime 300 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_dbd |
Cette directive définit la durée de vie des connexions inactives lorsque le nombre de connexions spécifié par la directive DBDKeep a été dépassé (plates-formes threadées seulement).
Description: | Exécute une instruction SQL après connexion à une base de données |
---|---|
Syntaxe: | DBDInitSQL "instruction SQL" |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_dbd |
Les modules qui le souhaitent peuvent exécuter une ou plusieurs instructions SQL après connexion à une base de données. Par exemple initialiser certaines valeurs, ou ajouter une entrée dans le journal lors d'une nouvelle connexion à la base de données.
Description: | Nombre maximum de connexions maintenues |
---|---|
Syntaxe: | DBDKeep nombre |
Défaut: | DBDKeep 2 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_dbd |
Cette directive définit le nombre maximum de connexions à maintenir par processus, en dehors de celles servant à gérer les pics de demandes (plates-formes threadées seulement).
Description: | Nombre maximum de connexions |
---|---|
Syntaxe: | DBDMax nombre |
Défaut: | DBDMax 10 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_dbd |
Cette directive définit le nombre maximum effectif de connexions par processus (plates-formes threadées seulement).
Description: | Nombre minimum de connexions |
---|---|
Syntaxe: | DBDMin nombre |
Défaut: | DBDMin 1 |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_dbd |
Cette directive définit le nombre minimum de connexions par processus (plates-formes threadées seulement).
Description: | Paramètres de la connexion à la base de données |
---|---|
Syntaxe: | DBDParams
param1=valeur1[,param2=valeur2] |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_dbd |
Cette directive spécifie des paramètres selon les besoins du pilote concerné. En général, les paramètres à passer concernent tout ce qui n'a pas de valeur par défaut comme le nom d'utilisateur, le mot de passe, le nom de la base de données, le nom d'hôte et le numéro de port de la connexion.
Les paramètres de la chaîne de connexion en fonction des différents pilotes comprennent :
PQconnectdb
partie1:partie2
est utilisé dans
sqlite_open(partie1, atoi(partie2), NULL)
sqlite3_open
Description: | Utiliser ou non des connexions persistentes |
---|---|
Syntaxe: | DBDPersist On|Off |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_dbd |
Si cette directive est définie à Off, les connexions persistentes et les connexions groupées sont désactivées. À la demande d'un client, une nouvelle connexion à la base de données est ouverte, et fermée immédiatement à l'issue du traitement. Cette configuration ne doit être utilisée qu'à des fins de débogage, ou sur des serveurs à charge faible.
Par défaut, les groupes de connexions persistentes sont activés (ou une seule connexion persistente du style LAMP pour les serveurs non threadés), et c'est la configuration qui devrait être utilisée dans la plupart des cas sur un serveur en production.
Avant la version 2.2.2, cette directive n'acceptait que les
valeurs 0
et 1
au lieu de Off
et On
, respectivement.
Description: | Définit une requête SQL préparée |
---|---|
Syntaxe: | DBDPrepareSQL "requête SQL" étiquette |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_dbd |
Pour les modules tels que les modules d'authentification, qui utilisent de manière répétée la même requête SQL, on peut optimiser les performances en préparant la requête une fois pour toutes au démarrage, plutôt qu'à chaque utilisation. Cette directive permet de préparer une requête SQL et de lui assigner une étiquette.
Description: | Spécifie un pilote SQL |
---|---|
Syntaxe: | DBDriver nom |
Contexte: | configuration du serveur, serveur virtuel |
Statut: | Extension |
Module: | mod_dbd |
Cette directive spécifie un pilote apr_dbd par son
nom. Le pilote doit être installé sur votre système (sur la plupart
des systèmes, il s'agit d'un objet partagé ou d'une dll). Par
exemple, DBDriver mysql
va sélectionner le pilote MySQL
dans la bibliothèque apr_dbd_mysql.so.