Luis Colorado A propos de l'Auteur:  Luis Colorado travaille comme administrateur de systèmes Unix et d'accès Internet pour Telefónica Sistemas S.A. en Espagne. Il est diplômé de Physique de Universidad Complutense à Madrid et a developpé plusieurs utilitaires libres pour Unix.  Contenu:  Introduction Motivation M4 Comment ça marche? Transférer des données de l'utilisateur vers la CGI Télécharger

PG2CGI: Accéder à une base de données depuis le web

Résumé:

Cet article décrit un programme qui permet d'accéder à une base de données depuis une page HTML. L'objectif de ce programme est le contrôle de l'accès aux données, la flexibilité de la configuration et l'indépendance vis à vis de la mise en page. Ce programme est le résultat d'une série d'idées provenant de la lecture de plusieurs articles sur M4 qui sont sortis récemment dans les magazines Linux Journal et LinuxFocus (www.linuxfocus.org) pendant ces 12 derniers mois.

Introduction

Motivation

De plus, la disponibilité de nombreux serveurs web et moteurs de base de données contraste avec le manque d'utilitaires qui permettent d'interfacer les 2 environnements (La majorité de ces applications sont commerciales ou ont de sérieuses insuffisances dans les formats qu'elles peuvent prendre en compte).

Le programme tente d'unifier les 2 mondes grâce à une application qui satisfait les points suivants:

M4

• M4 fut originellement développé pour lier la CGI (Common Gateway Interface) avec la base de données PostgreSQL. Rapidement, des gens ont réalisé qu'il était suffisamment général pour supporter d'autres interfaces (par exemple une passerelle entre une serveur LDAP et d'autres bases de données comme Informix ou Oracle). Plus tard, l'interface fut standardisée incorporant toutes les fonctionnalités nécessaires et les modules PostgreSQL furent réécris en fonction de la nouvelle interface. Maintenant, il est possible d'écrire de nouveaux pilotes qui permettent au programme de supporter d'autres gestionnaires de base de données.

• Il est utilisé pour remplacer les macros qui passent l'information de la gauche vers la droite dans les règles de sélection du fichier de configuration (voir la documentation pour plus d'informations).
• Il est aussi utilisé pour implémenter toutes les définitions, réalisées pour la consultation, par le modèle qui génère le fichier final au format HTML.
• Notre logiciel utilise aussi M4 en interne (plusieurs fois) pour réaliser les substitutions de variables qui sont transmises aux pilotes responsables du lancement des requêtes de base de données.

Expressions régulières:

• Le regroupement de plusieurs possibilités (équivalentes) dans une seule règle de configuration.
• Il n'y a pas de perte significative de performances. Les librairies courantes (GNU) pour les expressions régulières sont suffisamment efficaces pour justifier leur emploi.
• Les libriaires employées permettent le groupement de sous-expressions régulières (comme l'emploi de parenthèses) et l'identification de sous-chaînes dans l'expression originale. Cette fonctionnalité est idéale pour passer l'information aux pilotes (drivers) qui se chargent des requêtes.

Prenons un exemple: Supposons que le client doive nous transmettre des informations dans la QUERY_STRING, au format suivant:

CHAMP=Valeur

La mise en oeuvre de cette syntaxe se fait facilement en écrivant les termes suivants dans la règle de sélection:

 QUERY_STRING: "^CHAMP=[^&]*$";

 QUERY_STRING: "^CHAMP=([^&]*)$";

Comment cela fonctionne-t-il?

• Les variables d'environnement correspondent à une expression régulière donnée dans le fichier de configuration. Par exemple:

• QUERY_STRING:    "^CHAMP=([^&]*)$";
  

• Les variables d'environnement ne correspondent pas à une expression régulière du fichier de configuration. Ce type d'énoncé nous permet de rejeter une règle si certaines conditions sont dans la variable d'environnement spécifiée. Par exemple:

• ! HTTP_ADDRESS: "^194\.142\.12\.";

  (Cet exemple invalidera la règle si la requête vient de 194.142.12.xxx)
• Les variables d'environnement dont la valeur est optionnelle (ce n'est pas déterminant pour sélectionner la règle). Si la valeur est présente, l'information est transmise. Par exemple:

• [ QUERY_STRING: "UTILISATEUR=([^&]*)" ];

  Ces définitions nous permettent de transmettre la valeur de l'utilisateur si le client la fournit mais n'invalide pas la règle si le client ne la spécifie pas.

La partie gauche et la partie droite d'une règle sont délimitées par des accolades "{ }" et sont séparées par le symbole`->'.

La partie droite contient les termes avec une même syntaxe: un nom de variable, le caractère ':', une chaîne de caractères et le caractère fin de chaîne ';'. Tous les termes du coté droit sont des assignations de valeurs à des variables effectuées par M4.

• Puis, on lance M4 avec les délimiteurs échangés (remplacer ' par <<< et ' par >>>) et les commentaires désactivés; donc les caractères tels que #' n'interfèrent pas avec la chaîne de substitution. On assigne la valeur de la chaîne obtenue à la variable d'environnement nommée.
• PG2CGI utilise 3 variables d'environnement réservées:

• M4FILE

  Cette variable contient le nom de fichier pour le modèle de sortie de M4.

  DRIVER.

  Pointe sur le pilote (driver) à utiliser.

  TESTMODE

  Si sa valeur est "TRUE" (vrai), cela siginifie que la sortie doit-être en mode debug. En mode debug, PG2CGI n'appelle pas M4 dans la phase finale et le résultat est généré au format TEXT/PLAIN. Ce fichier, ainsi créé, est en principe, passé a M4 en mode normal

Comment les informations en provenance du client atteignent la CGI?

et la règle déclarée dans le site web est :

     QUERY_STRING: "NAME=([^&]*)";
     QUERY_STRING: "FAMNAME1=([^&]*)";
     QUERY_STRING: "FAMNAME2=([^&]*)";

     term_0_match_0  <- "NAME=JOSE";
     term_0_match_1  <- "JOSE";
     term_1_match_0  <- "FAMNAME1=DE LA FUENTE"
;  
           
(noté le remplacement du caractère + par ` ')
     term_1_match_1  <- "DE LA FUENTE";
     term_2_match_0  <- "FAMNAME2=LOPEZ";
     term_2_match_1  <- "LOPEZ";

Nous ne décrirons pas, dans cet article, l'utilisation des pilotes. Tout est déjà expliqué dans la documentation fournie avec la distribution de PG2CGI. Le lecteur intéressé est encouragé à lire le manuel de référence

Pour le moment, il n'existe qu'un seul pilote pour la connexion à la base de données PostgreSQL. Cependant, l'auteur a prévu d'écrire un autre pilote pour les bases de type LDAP.

Un exemple:

Examinons maintenant le source d'un exemple complet.

Considérons la table de déclarations provenant de la base de données de déclarations à slug.cvt.es (Suivez le lien "AVISO A LOS NAVEGANTES"). C'est un exemple très simple qui utilise 2 modèles pour voir des enregistrements individuellement ou une liste complète.

{
  PATH_INFO: "^/avisos/?$"; # Selectionne by PATH_INFO
  [SERVER_ADMIN: ".*"];     
# Obtient des informations de SERVER_ADMIN. Optionnel
} -> {
  DRIVER:   "POSTGRESQL";
  PGTTY:    "/dev/console";  # Envoie les log à la console
  PGDATABASE:     "postgres";
# Nous faisons une requête (Toujours écrire l'oid qui
# l'utilisera en interne dans le fichier modèle
# pour lier les enregistrements individuels).
  PGQUERY:  "select oid,ct,titulo,texto,mt"
      " from avisos"
      " where (dt is NULL or dt > 'now')"
      " order by mt desc";
# Fichier contenant le modèle
  M4FILE:    "/usr/local/etc/httpd/plantillas_m4/avisos.m4";
  WEBMASTER: "term_1_match_0";
  #TESTMODE: "TRUE";
}

# La règle de sélection suivante permet de sélectionner une déclaration (aviso)
# avec un OID connu (clé primaire ou primary key). L'information est incluse dans
# la variable PATH_INFO de la CGI.

{
  PATH_INFO: "^/avisos/([0-9]+)/?$";
  SERVER_ADMIN: ".*";
} -> {
  DRIVER:   "POSTGRESQL";
  PGTTY:    "/dev/console";  # Comme précédemment, permet 
d'écrire les "logs" sur la console
  PGDATABASE:     "postgres";
  OID:      "term_0_match_1"; # assigne un OID

# Encore une fois la sélection est importante. Nous incluons l'OID
# au début du champ pour le cas où nous souhaitons écrire
# un hyperlien pour effacer cet enregistrement.

  PGQUERY:  "select oid,ct,titulo,texto,mt,dt,autor"
            " from avisos"
            " where 
(dt is NULL or dt > 'now') and oid=OID";
# Le modèle est différent maintenant
  M4FILE:    "/usr/local/etc/httpd/plantillas_m4/avisos_oid.m4";
  WEBMASTER: "term_1_match_0";
  #TESTMODE: "TRUE";
}

Le résultat peut-être vu à ces adresses:
http://slug.ctv.es/cgi-bin/pg2cgi/avisos/
ou
http://slug.ctv.es/cgi-bin/pg2cgi/avisos/20384

Téléchargements