[TUTORIEL] VHCS2 - Exécution de programmes CGI dans un Rep. htdocs

M. DECLERCQ · Le 13/07/2006, à 03:11

MINI TUTORIEL - VHCS2 - Exécution de scripts CGI dans le répertoire htdocs d'un domaine ou sous-domaine géré par l'application VHCS2

DESCRIPTION DU TUTORIEL (Rédigé sur le tarmac pour Yohann ).

Ce tutoriel traite de la procédure à suivre pour pouvoir exécuter des programmes CGI dans le répertoire de son choix en se passant de la directive ScriptAlias.

Il a été rédigé spécialement pour un système disposant d'Ubuntu sur lequel l'application VHCS 2.4.7.1 a été préalablement installée mais peut aussi être suivi, avec quelques adaptations, sur des systèmes bénéficiant d'une simple solution LAMP ==> LINUX APACHE MYSQL PHP/PERL.

I. LE POURQUOI DE CE TUTORIEL

Lorsque vous installez l'application VHCS2 et que vous créez des domaines et sous-domaines via l'interface d'administration de cette application, les scripts (programmes) CGI, si actifs, peuvent êtres exécutés qu'à partir d'un répertoire bien particulier. Il s'agit du répertoire /cgi-bin/ qui se situe en dehors de l'arborescence Web.

Pour exemple, si vous créez le domaine nuxwin.com à partir de l'interface d'administration de l'application VHCS2, cela créra l'arborescence suivante :

/var/www/virtual/nuxwin.com
/var/www/virtual/nuxwin.com/htdocs
/var/www/virtual/nuxwin.com/cgi-bin
/var/www/virtual/nuxwin.com/logs
/var/www/virtual/nuxwin.com/errors

Remarque concernant l'arborescence Web :

Seul le répertoire htdocs fait parti de l'arborescence Web (Il s'agit du répertoire Web racine).

Comme vous le voyez, nous retrouvons bien notre réperoire cgi-bin à partir duquel les programmes CGI peuvent être éxécutés, ce dernier se trouvant, comme indiqué précédement, en dehors de l'arborescence Web.

Pour un sous-domaine, vous obtiendrez l'arborescence suivante :

Exemple pour le sous-domaine dev.nuxwin.com :

/var/www/virtual/nuxwin.com/dev
/var/www/virtual/nuxwin.com/dev/htdocs
/var/www/virtual/nuxwin.com/dev/cgi-bin

Là encore, nous retrouvons bien le répertoire cgi-bin à partir duquel les scripts (programmes) CGI peuvent être exécutés.

Ps : La remarque concernant l'arborescence Web s'applique aussi aux sous-domaines.

Ce faisant, dans certains cas, il peux être nécessaire/intéressant d'activer l'exécution des programmes CGI à partir du répertoire htdocs ou autre... En tous cas, cela a été le désir de Yohann, membre de notre communauté, qui me pousse aujourd'hui à rédigé cet écrit...

Je vais donc vous rappeler, dans un premier temps, les bases de l'exécution d'un programme CGI. Accrochez vous à votre fauteuille ou tabouret car il y a de la lecture...

CONSEIL : Avant de modifier quoi que ce soit sur votre système, lisez tranquillement et entièrement ce tutoriel.

II. DEFINITION DU TERME CGI

Le terme CGI (Common Gateway Interface) correspond à un shéma fonctionnel permettant à un Serveur Web d'exécuter des programmes écrits dans n'importe quel langage : Perl, C, Shell...

III. LA DIRECTIVE ScriptAlias

La directive ScriptAlias donnes accès à des programmes CGI stockés en dehors de l'arborescence Web. Ainsi, lorsque l'URL du navigateur (côté client) sollicite un tel alias, le Serveur Web Apache comprend qu'il ne s'agit pas d'une requête simple et déclenche alors l'exécution du programme CGI. Le programme doit fournir ses résultats sur sa sortie standart et le Serveur Web Apache se chargera d'envoyer cette réponse au navigateur du client.

Rappel concernant la directive ScriptAlias :

La directive ScriptAlias désigne l'emplacement d'exécution des scripts CGI. Sa syntaxe est de type : ScriptAlias chemin-URL chemin-fichier|chemin-répertoire.

Cette directive peut être insérée dans le fichier de configuration du Serveur Web Apache (ex : apache2.conf), et/ou dans les fichiers de configurations des sites virtuels (VirtualHost) (ex : vhcs2.conf).

Voici un exemple typique d'utilisation de la directive ScriptAlias dans un VirtualHost généré par les templates Apache de l'application VHCS2 :

# httpd [nuxwin.com] dmn entry BEGIN.
<VirtualHost 192.168.0.2:80>

#
#User vu2001
#Group vu2001
#

#
#SuexecUserGroup vu2001 vu2001
#
ServerAdmin hostmaster@nuxwin.com
DocumentRoot /var/www/virtual/nuxwin.com/htdocs

ServerName nuxwin.com
ServerAlias www.nuxwin.com nuxwin.com

ErrorLog /var/log/apache2/users/nuxwin.com-error.log
TransferLog /var/log/apache2/users/nuxwin.com-access.log

CustomLog /var/log/apache2/nuxwin.com-traf.log traff
CustomLog /var/log/apache2/nuxwin.com-combined.log combined

Alias /errors /var/www/virtual/nuxwin.com/errors/

ErrorDocument 401 /errors/401/index.php
ErrorDocument 403 /errors/403/index.php
ErrorDocument 404 /errors/404/index.php
ErrorDocument 500 /errors/500/index.php
# httpd dmn entry cgi support BEGIN.
ScriptAlias /cgi-bin/ /var/www/virtual/nuxwin.com/cgi-bin/
<Directory /var/www/virtual/nuxwin.com/cgi-bin>
AllowOverride None
#Options ExecCGI
Order allow,deny
Allow from all
</Directory>
# httpd dmn entry cgi support END.

<Directory /var/www/vhcs2/gui>
php_admin_value open_basedir "/var/www/vhcs2/gui/:/etc/vhcs2/:/proc/:/var/www/virtual/:/tmp/"
</Directory>
# httpd dmn entry PHP2 support BEGIN.
php_admin_value open_basedir "/var/www/virtual/nuxwin.com/:/usr/share/php/:/tmp/"
# httpd dmn entry PHP2 support END.

<Directory /var/www/virtual/nuxwin.com/htdocs>
# httpd dmn entry PHP support BEGIN.
# httpd dmn entry PHP support END.
Options Indexes Includes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>

</VirtualHost>

Comme vous le voyez, en gras, nous apercevons la directive ScriptAlias qui nous indique que le répertoire d'exécution des scripts CGI ou plus communément appelés programmes CGI est cgi-bin ce dernier étant situé dans le répertoire /var/www/virtual/nuxwin.com. Ce répertoire se trouve bien en dehors de l'arborescence Web qui, elle, commence dans le répertoire htdocs, le répertoire Web racine (DocumentRoot) du site virtuel.

Il en résulte que si nous tapons l'url suivante ==> http://nuxwin.com/cgi-bin/script.cgi, cela provoquera l'exécution du programme script.cgi qui se trouve dans le répertoire /var/www/virtual/nuxwin.com/cgi-bin.

Ps : Ne cherchez pas le programme script.cgi sur votre système. Il ne s'agit que d'un exemple...

ATTENTION : Pour que vos programmes CGI puissent être exécutés, il est important que le Serveur Web Apache possède les droits d'exécution sur ces programmes. En général, il suffit qu'un chmod 755 leur soit appliqué.

IV. HANDLER CGI-SCRIPT

Un Handler désigne une action associée à un fichier autrement que par son type. Quelques Handlers prédéfinis sont fournis avec le Serveur Web Apache2, notamment, le Handler cgi-script. C'est ce dernier qui nous intéresse dans le cadre de ce tutoriel.

Si vous éditez votre fichier apache2.conf, vous pourrez voir qu'une directive AddHandler pour l'exécution des programmes CGI est déjà présente mais commentée. Il s'agit de l'handler cgi-script évoqué ci-dessus.

Ainsi, grâce à cet Handler, tous les fichiers dont l'extension sera cgi pourront êtres considérés comme des programmes CGI.

Bien entendu, vous pouvez rajouter d'autres extentions à cet Handler.

Exemple :

AddHandler cgi-script .cgi .pl

Toutefois, l'activation de l'Handler cgi-script ne suffit pas pour que vos programmes CGI puissent s'exécuter. Il faut en effet que le répertoire dans lequels il se trouvent dispose de la directive Options suivie de l'argument ExecCGI. Sans cela, vous n'arriverez pas à exécuter vos programmes et obtiendrez une simple bôite de dialogue vous proposant de télécharger le fichier.

Bien entendu, pour que les changements soient pris en comptes, il faudra, comme usuellement, que vous rel-lanciez le Serveur Web Apache.

Pour ce faire, il vous suffira de taper la commande suivante dans un terminal :

sudo /etc/init.d/apache2 reload

V. EXEMPLE D'UTILISATION TYPIQUE :

Voici un exemple concrêt (Ne pas suivre cet exemple pour la gestion des domaines avec l'application VHCS2) :

Dans un premier temps, reprenons notre arborescence liminaire :

/var/www/virtual/nuxwin.com
/var/www/virtual/nuxwin.com/htdocs
/var/www/virtual/nuxwin.com/cgi-bin
/var/www/virtual/nuxwin.com/log
/var/www/virtual/nuxwin.com/errors

Comme nous l'avons vu précédement, il nous serait plus facile de placer nos programmes CGI dans le répertoire cgi-bin prévu à cet effet. Cependant, nous voulons placer (cette idée ne provient pas de moi lol) nos programmes CGI dans notre répertoire Web racine nommé ===> htdocs.

Nous allons donc placer notre premier programme CGI ==> mon-script.cgi dans le répertoire htdocs.

Ensuite, nous allons activer l'Handler évoqué ci-dessus en éditant notre fichier de configuration apache2.conf. Je rappelle pour la forme que ce fichier est situé dans le répertoire /etc/apache2

a. En mode graphique :

sudo gedit /etc/apache2/apache2.conf

b. En mode serveur :

sudo vi /etc/apache2/apache2.conf

Dans ce fichier, nous faisont une recherche sur addHandler cgi-script .cgi.

Une fois que nous avons trouvé la ligne concernée, nous la décommentons (on enlève simplement le signe # qui se trouve juste devant).

Au passage et dans la mesure ou certains des programmes CGI que nous allons employer portent l'extension pl, nous allons la rajouter à l'Handler prédéfini.

Nous avons donc :

AddHandler cgi-script .cgi

qui devient :

AddHandler cgi-script .cgi .pl

Ensuite, nous devons rajouter au réperoire Web racine htdocs, si elle n'est déjà pas présente, la directive Options ainsi que l'argument ExecCGI.

Pour ce faire, reprenons le fichier de configuration de notre VirtualHost ==> vhcs2.conf, tout du moins, la partie qui nous intéresse :

.....
ServerAdmin hostmaster@nuxwin.com
DocumentRoot /var/www/virtual/nuxwin.com/htdocs

ServerName nuxwin.com
ServerAlias www.nuxwin.com nuxwin.com

........
<Directory /var/www/virtual/nuxwin.com/htdocs>
Options Indexes Includes FollowSymLinks MultiViews ExecCGI
AllowOverride All
Order allow,deny
Allow from all
</Directory>

</VirtualHost>

La directive Options étant déjà présente dans notre fichier de configuration vhcs.conf. Nous avons simplement dû rajouter l'argument ExecCGI, aparaîssant en gras ci-dessus, pour que nos programmes CGI puissent êtres exécutés.

Enfin, nous relancons notre Serveur Web Apache pour que les modifications soient prises en comptes :

sudo /etc/init.d/apache2 force-reload

Une fois ceci effectué, il nous suffira de taper l'url http://nuxwin.com/mon-script.pl ou encore l'url http://nuxwin.com/mon-script.cgi[/b] dans la barre d'un navigateur internet pour que ce dernier soit exécuté.

NOTA : Normalement, et comme ci-dessus, nous devons rajouter la directive Options ainsi que l'argument ExecCGI pour que les programmes CGI puissent être exécutés en dehors de l'arborescense Web. Ce faisant, dans notre cas, les programmes CGI se trouvent dans notre arborescence Web ( au sein même de notre répertoire Web racine). N'ayant pas encore essayé sans, je ne suis pas certain que l'inclusion de ces deux "éléments" soit impérative dans ce dernier cas ???.

MISE EN GARDE : Si vous aviez déjà fait des tentatives d'exécution de programmes CGI placés dans un autre répertoire que celui prévu à cet effet ==> (cgi-bin) avant d'activer cette fonction, je vous recommande de vider le cache de votre navigateur et de le fermer (toutes les pages Web ouvertes) avant de retenter l'exécution.

VI : SOLUTION PARTICULIERE POUR L'APPLICATION VHCS2

1. Mais pourquoi donc une solution particulière pour l'application vhcs2 ?

Dans une première approche, nous aurions tendance à vouloir modifier directement le fichier de configuration des sites virtuels soit le fichier vhcs2.conf dans notre cas.

Oui mais :

Avec l'application VHCS2, la configuration des VirtualHosts est générée par des templates qui sont situés dans le répertoire /etc/vhcs2/apache/parts. La configuration des VirtualHosts générée est stockée dans un fichier qui se nomme vhcs2.conf et ce dernier se situe dans le répertoire ==> /etc/apache2/sites-enabled.

Nous rencontrons donc un problème majeur :

Si nous modifions directement la configuration d'un VirtualHost en éditant le fichier vhcs2.conf, les modifcations apportées seront automatiquement annulées dès que nous ajouterons un nouveau domaine, un sous-domaine ou encore, un alias de domaine via l'interface d'administration de l'application VHCS2. En effet, à chaque ajout, la configuration des VirtualHost sera complétement re-générée ce qui provoquera le remplaçement du fichier vhcs2.conf et par conséquent, l'annulation de nos modifications manuelles.

De la même manière, les modifications appliquées sur un VirtualHost seront annulées si nous re-générons nos fichiers de configuration via des requêtes SQL (cf. portail nuxwin.com pour plus d'explications à ce sujet...).

Cette possibilité est donc a écarter...

Dans un deuxième temps, ne pouvant modifier directement le fichier généré (vhc2.conf), nous aurions sûrement tendance à vouloir s'en prendre aux templates eux mêmes. Ce faisant, si nous modifions les templates et que nous re-générions nos fichiers de configuration (c'est obligatoire pour que les changements soient pris en comptes), les modifications apportées seraient effectives pour tous les sites virtuels, autrement dit, pour tous les répertoires htdocs de tous les domaines ou sous-domaines selon le template modifié.

Cette deuxième solution est donc aussi à écarter.

Toutefois il existe une autre solution, celle de la gestion décentralisée des répertoires grâce aux fichiers .htaccess.

2. Les fichiers de gestion décentralisée .htaccess

La plupart des utilisateurs pensent que les fichiers [/b].htaccess[/b] ne servent qu'à protéger un répertoire. Ceci est une fausse idée car ces fichiers permettent beaucoup plus de choses...

Comme indiqué ci-avant, il est possible de gérer des répertoires autrement qu'en passant par les fichiers de configuration d'Apache. Il suffit simplement de créer un fichier .htaccess à la racine du répertoire que l'on souhaite gérer.

Ceci est particulièrement intéressant lorsqu'un Administrateur Web souhaite décentraliser la gestion des répertoires Web de chaque utilisateur d'un Serveur Web. Cela peut notamment être le cas d'un Serveur Web gérant plusieurs domaines appartenant chacun à différents clients. Toutefois, convient-il de préciser que cela peut aussi être très dangereux en terme de sécurité et c'est pour cela que beaucoup d'hébergeurs, notamment ceux qui proposent des offres d'hébergements gratuit, désactivent cette fonction ou en limitent grandement l'utilisation.

a. Le nom des fichiers de gestion décentralisé vous fait peur ?

A ce stade, il convient d'ors-et-déjà de préciser que les fichiers .htaccess peuvent êtres nommés autrement, ceci grâce à la directive AccessFileName

Cette directive se trouve dans le fichier de configuration apache2.conf. Voici à quoi elle ressemble dans le cadre d'une utilisation usuelle :

AccessFileName .htaccess

Pour exemple , si nous voulions que nos fichiers de gestion décentralisée se nomment .drakpper au lieu de .htaccess , il nous suffirait de modifier la ligne évoquée ci-dessus de cette manière :

AccessFileName .drakpper

De même, il faudrait effectuer une deuxième modification :

Nous devrions remplacer ce qui suit :

<Files ~ "^\.ht">
Order allow,deny
Deny from all
</Files>

Par ceci :

<Files ~ "^\.dr">
Order allow,deny
Deny from all
</Files>

Et enfin, nous devrions relancer notre Serveur Web Apache pour que les changements soient pris en comptes :

sudo /etc/init.d/apache2 force-reload

b. Et la sécurité alors ?

Comme évoqué au début de ce paragraphe, il est possible de limiter l'utilisation des fichiers de gestion décentralisée. Ceci peut être mis en place grâce à la directive AllowOverride.

Petit rappel concernant la directive AllowsOverride :

Cette directive sert à contrôler l'utilisation des fichiers de gestion décentralisée .htaccess. Sa syntaxe est de type : AllowOverride All|None|type-de-directive

Exemple concrêt de syntaxes et leurs significations :

AllowOverride All
Toutes les directives valides sont autorisées dans les fichiers .htaccess

AllowOverride None
Aucune directive n'est autorisée se qui rend les fichiers .htaccess non opérationnels

AllowOverride Options
L'utilisation de la directive Options est possible dans les fichiers .htaccess

Ps : Il existe d'autres arguments disponibles pour la directive AllowOverride, renseignez-vous...

3 : Mise en application pour l'exécution de programmes CGI dans le répertoire [b]htdocs d'un domaine ou sous-domaine géré par l'application VHCS2.[/b]

Ps : Dans cette exemple, il s'agirat du sous-domaine dev du domaine nuxwin.com ==> dev.nuxwin.com

Remarque à titre liminaire :

Par défaut (c'est complétement con ! ! ! - vive la sécurité...), lorsqu'on créer un sous-domaine, via l'interface d'administration de VHCS2, le fichier vhcs2.conf suivant est généré :

Ps : je ne reporte que la configuration du sous-domaine concerné car, la configuration de tous les sites virtuels est stockées dans le même fichier avec l'application VHCS2).

# httpd [nuxwin.com] dmn group entry BEGIN.
# httpd [dev.nuxwin.com] sub entry BEGIN.
<VirtualHost 192.168.0.2:80>
#
#User vu2001
#Group vu2001
#

#
#SuexecUserGroup vu2001 vu2001
#
ServerAdmin root@nuxwin.com
DocumentRoot /var/www/virtual/nuxwin.com/dev/htdocs

ServerName dev.nuxwin.com
ServerAlias www.dev.nuxwin.com dev.nuxwin.com *.dev.nuxwin.com

ErrorLog /var/log/apache2/users/dev.nuxwin.com-error.log
TransferLog /var/log/apache2/users/dev.nuxwin.com-access.log

CustomLog /var/log/apache2/nuxwin.com-traf.log traff
CustomLog /var/log/apache2/nuxwin.com-combined.log combined
Alias /errors /var/www/virtual/nuxwin.com/errors/
<Directory /var/www/virtual/nuxwin.com/errors/>
php_admin_value open_basedir "/var/www/virtual/nuxwin.com/errors/"
</Directory>
ErrorDocument 401 /errors/401/index.php
ErrorDocument 403 /errors/403/index.php
ErrorDocument 404 /errors/404/index.php
ErrorDocument 500 /errors/500/index.php
# httpd sub entry cgi support BEGIN.
ScriptAlias /cgi-bin/ /var/www/virtual/nuxwin.com/dev/cgi-bin/
<Directory /var/www/virtual/nuxwin.com/dev/cgi-bin>
AllowOverride None
#Options ExecCGI
Order allow,deny
Allow from all
</Directory>
# httpd sub entry cgi support END.
<Directory /var/www/vhcs2/gui>
php_admin_value open_basedir "/var/www/vhcs2/gui/:/etc/vhcs2/:/proc/:/var/www/virtual/:/tmp/"
</Directory>
# httpd sub entry PHP2 support BEGIN.
php_admin_value open_basedir "/var/www/virtual/nuxwin.com/dev/:/usr/share/php/:/tmp/"
# httpd sub entry PHP2 support END.

<Directory /var/www/virtual/nuxwin.com/dev/htdocs>
# httpd sub entry PHP support BEGIN.
# httpd sub entry PHP support END.
Options Indexes Includes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>

</VirtualHost>

Ce qui nous intéresse ici, c'est la dernière strophe que j'ai fait ressortir en gras.

Comme vous pouvez aisément le constater, la directive AllowsOverride ainsi que l'argument All sont déjà présent. Cela signifie d'une part que les fichiers .htaccess sont opérationnels par défaut et pire (argument All), que toutes les directives disponibles dans ce contexte sont autorisées pour le répertoire htdocs ainsi que ses sous-répertoires éventuels...

Nous n'aurons donc pas à modifier cette directive bien que cela ne soit pas ce qu'on pourrait appeler le TOP en terme de sécurité... Le même problème se pose lorsqu'on créer un nouveau domaine via l'interface d'administration de vhcs2...

Nous noterons aussi que la directive Options ainsi que les arguments suivants : Indexes Includes FollowSymLinks MultiViews[b] sont déjà présent dans la configuration du VirtualHost ([b]fichier vhcs2.conf).

Il nous reste donc deux choses à faire pour que l'exécution de programmes CGI soit possible à partir de notre répertoire Web racine htdocs :

- La création du fichier .htaccess;
- La configuration du fichier .htaccess.

1. Création du fichier .htaccess

Nous allons dès à présent créer un fichier .htaccess dans notre répertoire Web racine htdocs.

Pour ce faire, il nous suffit de taper la commande suivante dans un terminal :

a. En mode graphique

sudo gedit /var/www/virtual/nuxwin.com/dev/htdocs/.htaccess

b. En mode serveur

sudo vi /var/www/virtual/nuxwin.com/dev/htdocs/.htaccess

2.Configuration du fichier .htaccess

Une fois le fichier .htaccess créé et en cours d'édition, il nous suffit de rajouter l'Handler cgi-script et les bonnes directives et argument pour que nos programmes CGI puissent s'exécuter à partir de notre répertoire Web Racine htdocs :

Il vous suffit donc de rajouter ceci dans le fichier .htaccess que vous venez de créer et qui est en cours d'édition :

Options +ExecCGI
AddHandler cgi-script .cgi

ou

Options +ExecCGI
AddHandler cgi-script .cgi .pl

Si vous voulez que les fichiers portant l'extension .pl et qui se trouvent dans le répertoire htdocs soient considérés comme des programmes CGI.

Et enfin de sauvegarder le fichier.

Ps : Pensez à appliquer les bonnes permissions sur le fichier .htaccess que vous venez de créer. Evitez d'accorder les permissions d'écriture sur ce fichier. Un chmod 444 est largement suffisant ! De même, il est préférable que ce fichier appartienne au groupe apache ==> souvent, il s'agit de www-data.

Ps : Le reload du Serveur Web Apache n'est pas utiles dans le cas d'un fichier de gestion décentralisée car ce dernier est lu à chaque requête.

MISE EN GARDE : Si vous aviez déjà fait des tentatives d'exécution de programmes CGI placés dans un autre répertoire que celui prévu à cet effet ==> (cgi-bin), avant d'activer cette fonction, je vous recommande de vider le cache de votre navigateur et de le fermer (toutes les pages Web ouvertes) avant de retenter l'exécution.

ATTENTION : Pour que vos programmes CGI puissent être exécutés, il est important que le Serveur Web Apache possède les droits d'exécution sur ces programmes. En général, il suffit qu'un chmod 755 leur soit appliqué.

Ps : Je développerais la dernière partie un peux plus après avoir dormi car là, je suis extrêmement fatigué.

Si vous le désirez, vous pouvez tester l'exécution de programme cgi situé dans le répertoire htdocs du sous-domaine dev de mon domaine nuxwin.com avec l'application PG-TestScript éditée par Reynette pour vous rendre compte que la procédure annoncée ci-dessus fonctionne parfaitement :

Ps : En arrivant sur la page de connection vous devez entrer le mot de passe ci-dessous et après, il vous sera possible de tester l'exécution des scripts pg-testscript.pl et pg-testserveur.cgi en cliquant sur le bouton Test situé en bas de la page.

Clique --> Oui, je veux tester le résultat de cette procédure sur le serveur de Nuxwin <-- Clique

Le mot de passe est : passe

Je précise qu'il est inutile de tenter de modifier le mot de passe car j'ai interdit l'écriture dans le fichier concerné.

PRECISIONS :

Ce tutoriel à été rédigé dans un souci de clareté pour que tous les utilisateurs puissent comprendre de quoi il s'agit exactement.

La procédure évoquée a été testée avec succès sur un système disposant d'Ubuntu Dapper Drake sur laquelle l'application VHCS version 24.7.1 a préalablement été installée, cette dernière étant couplée à Apache/2.0.55 (Ubuntu) PHP/4.4.2-1build1 ainsi qu'au Serveur Mysql 5.0.22.

Pour tous renseignements complémentaires ou suggestions concernant ce tutoriel, je vous remercie de me contacter directement à cette adresse ==> redaction@nuxwin.com
_______________________________
Bien cordialement ;
Monsieur Laurent DECLERCQ

Dernière modification par M. DECLERCQ (Le 14/07/2006, à 17:04)

yohann · Le 13/07/2006, à 17:08

merci beaucoup,
Je viens d'essayer, ca marche au poil!

je ne connaissait pas l'existance des fichiers .htaccess!
la solution est beaucoup plus simple grace à eux.
deux ligne dans htaccess et hop
en plus cela a l'avantage de fonctionner même sur un serveur ou on a pas accès au fichier de conf d'apache(pour peu que la directive allowOverride soit spécifé correctement): excellent

le tutoriel est très bien fait mais je ne comprend pas bien la partie sur la directive scriptalias, qui me laisse supposer que je pourrait bien ne même pas avoir a utiliser de fichier .htaccess mais vraimement éxécuter les script cgi dans le repertoire qui leur est dédiés.

mais je ne veux pas toucher au code des script ou des pages html car je les heberge seulement.

la personne qui a fait le site a mis quelque chose du type

 
<form action="log_utilisateur.cgi" method="post" name="form_login" id="form_login">

pour appeler le script log_utilisateur.cgi depuis la page log_utilisateur.html.
ce qui signifie (pour moi) que le script log_utilisateur.cgi doit être placé dans le même repertoire que log_utilisateur.html.

donc toujour si j'ai bien compris la personne qui a fait le site aurait du mettre

<form action="http://es.proximum.org/cgi-bin/log_utilisateur.cgi" method="post" name="form_login" id="form_login">

a la place?

ou alors le scriptalias fait que comme on appel un fichier .cgi, il va automatiquement chercher log_utilisateur.cgi dans le repertoire cgi-bin

malgré ces quelques points obscures je crois avoir beaucoup mieux compris comment fonctionne apache, et c'est bein grace a toi!

Dernière modification par yohann (Le 13/07/2006, à 17:14)

M. DECLERCQ · Le 13/07/2006, à 18:42

Bonsoir ;

Si tu veux plus de renseignement concernant l'appel d'un script CGI via formulaire inséré dans une page HTML, je te recommande de consulter ce lien et de lire attentivement :

http://fr.selfhtml.org/cgiperl/introduction/cgihtml.htm

Maintenant ce que tu soulèves est effectivement possible et normalement, c 'est ce que ton client aurait du faire depuis le début (placer ses programmes CGI dans le répertoire cgi-bin.

Maintenant, tu dois savoir qu'un programme CGI peut recevoir des données de défférentes manières, notamment via des formulaires HTML.

Il existe plusieurs méthode pour le faire, notamment, la méthode GET et la méthode POST cette dernière étant la plus utilisée. Renseigne toi sur la différence entre ces deux méthode. Ce que je peux te dire c'est que pour la première méthode GET, les données sont ajoutées à l'URL référençant le script CGI. En ce qui concerne la deuxième méthode POST, les données ne sont pas ajoutées à l'URL...
____________________________
Bien cordialement ;
Monsieur Laurent DECLERCQ

Dernière modification par M. DECLERCQ (Le 14/07/2006, à 17:02)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 13/07/2006, à 03:11

[TUTORIEL] VHCS2 - Exécution de programmes CGI dans un Rep. htdocs

#2 Le 13/07/2006, à 17:08

Re : [TUTORIEL] VHCS2 - Exécution de programmes CGI dans un Rep. htdocs

#3 Le 13/07/2006, à 18:42

Re : [TUTORIEL] VHCS2 - Exécution de programmes CGI dans un Rep. htdocs

Pied de page des forums