Admin CliCours
Formation PHP manuel de référence, tutoriel & guide de travaux pratiques en pdf.
Problèmes?
Consultez la FAQ
Certains problèmes sont plus courants que d’autres. La solution aux problèmes les plus courants sont rassemblés dans la FAQ PHP, disponibles à l’adresse http://www.php.net/FAQ.php.
Rapporter un bug
Si vous pensez que vous avez trouvé un bug dans PHP, veuillez le faire savoir. Les développeurs PHP ne le connaissent probablement pas, et si vous ne le faites pas connaître, il n’y a aucune chance que celui-ci soit corrigé. Vous pouvez le faire savoir en utilisant le bug-tracking système à l’adresse http://www.php.net/bugs.php.
Autres problèmes
Si vous êtes toujours dans l’impasse, il y a probablement quelqu’un sur la liste de diffusion PHP qui pourra vous aider. Vous devriez déjà vérifier dans les archives de la liste de diffusion au cas oú quelqu’un aurait déjà répondu à votre question. Les archives sont accessibles à partir de la page « support » à l’adresse http://www.php.net/. Pour s’inscrire sur la liste de diffusion PHP, envoyer un message vide à l’adresse suivante: L’adresse de la liste de diffusion est: php-general@lists.php.net.
Si vous voulez obtenir de l’aide sur la liste de diffusion, veuillez essayer de préciser votre environnement (quel OS, quelle version de PHP, quel serveur web, si vous utilisez PHP comme CGI ou commer module serveur, etc…), et donnez assez de code afin que les membres de la liste puissent reproduire votre problème et le tester.
Introduction
Qu’est ce que PHP?
PHP (officiellement « PHP: Hypertext Preprocessor ») est un langage de script HTML, qui fonctionne coté serveur.
Réponse simple et claire, mais qu’est ce que cela veut dire? Un exemple :
<html>
<head>
<title>Exemple</title>
</head>
<body>
<?php echo « Salut, je suis un script PHP! »; ?>
</body>
</html>
Il est à noter la différence avec les autres scripts CGI écrit dans d’autres langages tels que le Perl ou le C : Au lieu d’écrire un programme avec de nombreuses lignes de commandes afin d’afficher une page HTML, vous écrivez une page HTML avec du code inclus à l’intérieur afin de réaliser une action précise (dans ce cas là, afficher du texte). Le code PHP est inclus entre 9.1.1 Le passage du HTML au PHP qui permettent au navigateur de passer en « mode PHP ».
Ce qui distingue le PHP des langages de script comme le Javascript est que le code est exécuté sur le serveur. Si vous avez un script similaire sur votre serveur, le client ne reçoit que le résultat du script, sans aucun moyen d’avoir accès au code qui a produit ce résultat. Vous pouvez configurer votre serveur web afin qu’il analyse tous vos fichiers HTML comme des fichiers PHP. Ainsi, il n’y a aucun moyen de distinguer les pages qui sont produites dynamiquement des pages statiques.
Que peut faire PHP pour vous?
Le langage PHP possède les même fonctionnalités que les autres langages permettant d’écrire des scripts CGI, comme collecter des données, générer dynamiquement des pages web ou bien envoyer et recevoir des cookies.
La plus grande qualité et le plus important avantage du langage PHP est le support d’un grand nombre de bases de données. Réaliser une page web dynamique interfacant une base de donnés est extrêmement simple. Les bases de données suivantes sont supportées par PHP:
Adabas D
dBase
Empress
FilePro
Informix
InterBase
mSQL
MySQL
Oracle
PostgreSQL
Solid
Sybase
Velocis
Unix dbm
Le langage PHP inclus le support des services utilisant les protocoles tels que IMAP, SNMP, NNTP, POP3 ou encore HTTP. Vous pouvez également ouvrir des connections et interagir en utilisant d’autres protocoles.
La génèse du PHP
Le langage PHP a été conçu durant l’automne 1994 par Rasmus Lerdorf. Les premières versions (qui restèrent privées) étaient utilisées afin de savoir qui venait consulter son CV en ligne. La première version publique fut disponible au début de l’année 1995. Elle fut connue sous le nom de « Personal Sommaire Page Tools ». Elle était composée d’un analyseur extrêmement simple qui ne reconnaissait que quelques marco spéciales et d’un petit nombre d’utilitaires couramment utilisés dans les pages web. Un guestbook, un compteur, etc… L’analyseur fut réécrit durant l’été 1995 et fut appelé PHP/FI Version 2. FI etaient les initiales d’un autre package que Rasmus avait écrit qui interprétait les formulaires HTML. C’est alors qu’il combina le « Personnal Sommaire Page tools » avec le « Form Interpreter » et il y ajouta le support de mSQL: c’est comme cela que naquît PHP/FI. PHP/FI grandit de manière spectaculaire et de nombreuses personnes commencèrent à contribuer à son amélioration.
Il est relativement peu aisé de donner des statistiques, mais on estime que PHP/FI est utilisé sur 15 000 sites web dans le monde entier, fin 1996. Ce chiffre atteint 50 000 durant l’été 1997. L’été 1997 voit aussi un profond changement dans le développemnt du PHP: d’un projet personnel (celui de Ramsus),* on passe alors à une projet d’équipe. L’analyseyr parseur fut de nouveau réécrit par Zeev Suraskyi et Andi Gutmans et ce nouvel analyseur forma la base de la version 3 du PHP. Une grande partie du code de PHP/FI fut complètement réécrit alors que l’autre partie fut portée pour donner le PHP Version 3.
Aujourd’hui (été 1999) PHP/FI ou PHP3 sont distribués avec de nombreux produits commerciaux comme « C2’s StrongHold web server » et « RedHat Linux » et il est admis (d’après les chiffres de NetCraft, et leurs statistiques Netcraft Web Server Survey) que le PHP est utilisé sur 150 000 sites web dans le monde entier. Pour comparaison, ce chiffre est supérieur au nombre de serveur tournant sous Netscape Enterprise server.
Enfin, à l’heure oú ce document est rédigé, la nouvelle génération du PHP est en cours de création. Elle utilisera les qualités de Zend pour améliorer les performances et améliorera le support des seveurs web autre que Apache.
Sécurité
PHP est un langage puissant et l’interpréteur, qu’il soit inclus dans le serveur web ou bien compilé en version CGI, est capable d’accéder aux fichiers, d’exécuter des commandes et d’ouvrir des connexions réseaux. Toutes ces propriétés fragilise la sécurité d’un serveur web. Le langage PHP a été pensé afin d’être un langage beaucoup plus sécurisé pour écrire des CGI que le Perl ou le langage C. De plus une sélection rigoureuse des options de compilation et d’exécution vous permettront d’obtenir un équilibre parfait entre liberté et sécurité.
Etant donné qu’il y a de nombreux moyens d’utiliser le langage PHP, il y a de nombreuses directives de configuration afin d’en contrôler le comportement. Un grand nombre d’options permettent d’utiliser le PHP dans de nombreuses situations, mais cela signifie aussi qu’il y a certaines combinaisons d’options de compilation et d’exécution qui fragilise la sécurité du serveur. Ce chapitre explique comme les différentes options de configurations peuvent être combinées, tout en conservant une sécurité maximum.
CGI binary
Faiblesses connues
Utiliser le PHP comme un CGI exécutable vient la plupart du temps du fait que l’on ne veut pas l’utiliser comme un module du serveur web, (comme Apache), ou bien que l’on souhaite l’utiliser en combinaison d’un CGI complémentaire, afin de créer un environnement de script sécurisé (en utilisant des techniques de chroot ou setuid). Une telle décision signifie habituellement que vous installez votre exécutable dans le
répertoire cgi-bin de votre serveur web. CERT CA-96.11 recommande effectivement de placer l’interpréteur à l’intérieur du répertoire cgi-bin. Même si le binaire PHP peut être utilisé comme interpréteur indépendant, PHP a été pensé afin de rendre impossible les attaques que ce type d’installation induit.
Accès au système de fichier: `http://ma.machine/cgi-bin/php?/etc/passwd’
Lorsque la requête est passée dans une url, après le point d’interrogation (?), elle est envoyée à l’interpréteur comme une ligne de commande par l’interface CGI. Habituellement, l’interpréteur ouvre le fichier spécifié et l’exécute.
Lorsqu’il est invoqué comme exécutable CGI, le PHP refuse d’interpréter les arguments de la ligne de commande.
Accès d’un document web sur le serveur : `http://my.host/cgi-bin/php/secret/doc.html’
Le « path information » dans l’url, situé juste après le nom du binaire PHP, `/secret/doc.html’ est utilisé par convention pour spécifier le nom du fichier qui doit être ouvert et interprété par le programe CGI. Habituellement, des directives de configuration du serveur web (pour le serveur Apache: Action) sont utilisées pour rediriger les requêtes pour obtenir un document `http://my.host/secret/script.php3′ par l’interpréteur PHP. Dans une telle configuration, le serveur web vérifie d’abord si il a accès au répertoire `/secret’, et après cette vérification redirige la requête vers `http://my.host/cgi-bin/php/secret/script.php3′. Malheureusement, si la requête est faite directement sous cette forme, aucune vérification d’accès n’est faite par le serveur web pour le fichier `/secret/script.php3′, mais uniquement pour le fichier `/cgi-bin/php’. De cette manière, n’importe quel utilisateur qui peut accéder au fichier `/cgi-bin/php’ peut aussi accéder au document protégés sur le serveur web.
Avec le PHP, l’option de compilation 4.2.7.16 –enable-force-cgi-redirect et les options
d’exécution 7.1.1.6 ini.doc-root et 7.1.1.27 ini.user-dir peuvent être utilisées pour
prévenir ce genre d’attaques, si des restrictions d’accès sont appliquées sur les documents du serveur. Voir ci-dessous pour des explications plus complètes sur les différentes combinaisons.
Cas 1: Tous les fichiers sont publics
Si votre serveur n’a aucun document dont l’accès est restreint par un mot de passe ou un système de vérification de l’adresse IP, vous n’avez aucun besoin de ce type de configuration. Si votre serveur web ne permet pas les redirections, ou si votre serveur web n’a aucun besoin de communiquer avec le binaire PHP de manière sécurisée, vous pouvez utiliser l’option de compilation 4.2.7.16 –enable-force-cgi-redirect. Vous devez quand même vérifier qu’aucun script ne fait appel au PHP, de manière directe, `http://my.host/cgi-bin/php/dir/script.php3′ ou bien de manière indirecte, par redirection,`http://my.host/dir/script.php3′.
Les redirections peuvent être configurées dans les fichiers de configuration d’Apache en utilisant les directives « AddHandler » et « Action » (voir ci-dessous).
Cas 2: Utilisation de la directive de compilation –enable-force-cgi-redirect
Cette option de compilation prévient quiconque d’appeler directement un script avec l’url `http://my.host/cgi-bin/php/secretdir/script.php3′. Dans ce cas là, PHP parsera le fichier uniquement si il y a eu redirection. Habituellement, le serveur web Apache réalise une redirection grâce aux directives suivantes :
Action php3-script /cgi-bin/php AddHandler php3-script .php3
Cette option a uniquement été testée avec Apache et compte sur Apache pour affecter la variable d’environnement non-standart REDIRECT_STATUS pour les requêtes redirigées. Dans le cas oú votre serveur web ne supporte pas le renseignement du PHP, pour savoir si la requête a été redirigée ou non, vous ne pouvez pas utiliser cette option de compilation. Vous devez alors utiliser une des autres manières pour utiliser la version binaire CGI du PHP, comme exposé ci-dessous.
Cas 3: Utilisation du « doc_root » ou du « user_dir »
Ajouter un contenu interactif dans votre serveur web, comme des scripts ou des exécutables, est souvent considéré comme une pratique non-sécurisée. Si, par erreur, le script n’est pas exécuté mais affiché comme une page HTML classique, il peut en résulter un vol de propriété intellectuelle ou des problèmes de sécurité à propos des mots de passe notamment. Donc, la plupart des administrateurs préfèrent mettre en place un répertoire spécial pour les scripts qui est uniquement accessible par le biais du binaire CGI du PHP, et donc, tous les fichiers de ce répertoire seront interprétés et non affichés tels quel.
Aussi, si vous ne pouvez pas utiliser la méthode présentée ci-dessus, il est nécessaire de mettre en place un répertoire « doc_root » différent de votre répertoire « document root » de votre serveur web.
Vous pouvez utiliser la directive 7.1.1.6 ini.doc-root dans le 7.1 Le fichier de configuration,
ou vous pouvez affecter la variable d’environnement PHP_DOCUMENT_ROOT. Si cette variable d’environnement est affectée, le binaire CGI du PHP construira toujours le nom de fichier à ouvrir avec doc_root et le « path information » de la requête, et donc vous serez sûr qu’aucun script n’est exécuté en dehors du répertoire prédéfinit. (à l’exception du répertoire désigné par la directive user_dir Voir ci-dessous).
Une autre option possible ici est la directive 7.1.1.27 ini.user-dir. Lorsque la directive n’est pas activée, seulement les fichiers contenues dans le répertoire doc_root peuvent être ouverts. Ouvrir un fichier possédant l’url `http://my.host/~user/doc.php3′ ne correspond pas à l’ouverture d’un fichier sous le répertoire racine de l’utilisateur mais à l’ouverture du fichier `~user/doc.php3′ sous le repertoire « doc_root » (oui, un répertoire comment par un tilde [~]).
Si la directive « user_dir » est activée à la valeur `public_php’ par exemple, une requête du type `http://my.host/~user/doc.php3′ ouvrira un fichier appelé `doc.php3′ sous le répertoire appelé `public_php’ sous le répertoire racine de l’utilisateur. Si le répertoire racine des utilisateurs est `/home/user’, le fichier exécuté sera `/home/user/public_php/doc.php3′.
user_dir et doc_root sont deux directives totalement indépendantes et donc vous pouvez contrôler l’accès au répertoire « document root » séparément des répertoires « user directory ».
Cas 4: L’exécutable PHP à l’extérieur de l’arborescence du serveur
Une solution extrêmement sécurisée consiste à mettre l’exécutable PHP à l’extérieur de l’arborescence du serveur web. Dans le répertoire `/usr/local/bin’, par exemple. Le problème de cette méthode est que vous aurez à rajouter la ligne suivante :
#!/usr/local/bin/php dans tous les fichiers contenant des tags PHP. Vous devrez aussi rendre le binaire PHP exécutable. Dans ce cas-là, traitez le fichier exactement comme si vous aviez un autre script écrit en Perl ou en sh ou en un autre langage de script qui utilise #! comme mécanisme pour lancer l’interpréteur lui-même. itself. Pour que l’exécutable PHP prenne en compte les variables d’environnement PATH_INFO et PATH_TRANSLATED correctement avec cette configuration, vous devez utiliser l’option de compilation
• 1 Préface
o 1.1 A propos de ce manuel
• 2 Préface
o 2.1 Les auteurs
o 2.2 Copyright
• 3 Copyright, distribution, historique
• 4 Installation
o 4.1 Télécharger la dernière version
o 4.2 Installation sous UNIX
o 4.3 Installation sous Windows 95/98/NT
o 4.4 Problèmes?
• 5 Introduction
o 5.1 Qu’est ce que PHP?
o 5.2 Que peut faire PHP pour vous?
o 5.3 La genèse du PHP
• 6 Sécurité
o 6.1 CGI binary
o 6.2 Module Apache
• 7 Configuration
o 7.1 Le fichier de configuration
• 8 Caractéristiques
o 8.1 Gestion des connexions
o 8.2 Cookies
o 8.3 Gestion des erreurs
o 8.4 Gestion des chargements de fichier
o 8.5 Authentification HTTP avec PHP
o 8.6 Création d’images
o 8.7 Connexions persistantes aux bases de données
o 8.8 Utilisation des fichiers à distance
• 9 Langage
o 9.1 La syntaxe de base
o 9.2 Les constantes
o 9.3 Les structures de contrôle
o 9.4 Les expressions
o 9.5 Fonctions
o 9.6 Classes et objets
o 9.7 Les opérateurs
o 9.8 Types
o 9.9 Les variables
o 9.10 Les références
• 10 Fonctions
o 10.1 spécifiques à Apache
o 10.2 Tableaux
o 10.3 Aspell
o 10.4 mathématiques sur des nombres de taille arbitraire
o 10.5 de calendrier
o 10.6 API CCVS
o 10.7 Classe/Objet
o 10.8 Support COM pour Windows
o 10.9 ClibPDF
o 10.10 CURL
o 10.11 de paiement Cybercash
o 10.12 de dates et heures
o 10.13 dbm
o 10.14 dBase
o 10.15 dbm
o 10.16 Accès aux dossiers
o 10.17 Chargement dynamique de fonctions
o 10.18 DOM XML
o 10.19 Fonction d’exécution de programmes
o 10.20 Forms Data Format
o 10.21 filePro
o 10.22 Système de fichiers
o 10.23 FTP
o 10.24 Fonctions GNU Gettext
o 10.25 HTTP
o 10.26 Hyperwave
o 10.27 InterBase
o 10.28 ICAP
o 10.29 Informix
o 10.30 sur les images
o 10.31 IMAP
o 10.32 Options PHP & informations
o 10.33 LDAP
o 10.34 Fonction mail
o 10.35 mathématiques
o 10.36 MCAL
o 10.37 de cryptage
o 10.38 Hash
o 10.39 diverses
o 10.40 functions mSQL
o 10.41 Microsoft SQL Server
o 10.42 MySQL
o 10.43 réseau
o 10.44 NIS
o 10.45 Oracle 8 functions
o 10.46 Oracle
o 10.47 Expressions régulières compatibles Perl
o 10.48 PDF
o 10.49 Fonctions de paiement Verisign
o 10.50 PostgreSQL
o 10.51 POSIX
o 10.52 Pspell
o 10.53 GNU Readline
o 10.54 Fonction GNU Recode
o 10.55 Expressions régulières
o 10.56 Sémaphores et gestion de la mémoire partagée
o 10.57 Gestion des sessions
o 10.58 SNMP functions
o 10.59 de chaîne de caractères
o 10.60 Shockwave Flash
o 10.61 d’accès à Sybase
o 10.62 ODBC
o 10.63 URL
o 10.64 sur les variables
o 10.65 Vmailmgr
o 10.66 WDDX functions
o 10.67 Analyseur syntaxique XML
o 10.68 YAZ
o 10.69 Compression
• Index des fonctions
• Index des concepts
Télécharger le cours complet
