Cours de PHP 5

Active ou désactive le tag « <? » (par opposition à « <?php ») pour ouvrir un bloc PHP dans le script.

Activer cette directive est utile pour conserver la compatibilité avec d’anciens scripts (notamment de l’époque de PHP3), mais une bonne pratique est plutôt de réécrire les scripts de cette époque à cause de leur ancienneté. Les pratiques de sécurité ont changé depuis l’époque de PHP3. Ce tag apporte l’inconvénient de générer des erreurs de syntaxe lorsque l’on veut servir des documents XML sur le même serveur, puisque c’est le même type d’ouverture de balise : « <?xml », reconnu par php.ini comme une ouverture de bloc PHP, ce qui est bien sûr incorrect.

Désactiver cette directive est considéré comme une bonne pratique. Il en va de même pour asp_tags, qui devrait être réservé au langage ASP.

Configuration recommandée :

• Développement : Off ;
• Production : Off.

Cette directive est habituellement désactivée, car la majorité des applications n’en ont pas besoin. De plus, celles qui utilisent ce type de buffer ont généralement un besoin très particulier qu’il est préférable de manipuler dans le script lui-même par la fonction ob_start().

Configuration recommandée :

• Développement : Off ;
• Production : Off.

Le Safe Mode a beaucoup fait parler de lui, à tel point que le PHP Group prévoit de totalement le supprimer de la configuration.

Le problème de cette directive est que son nom promet un niveau de sécurité qu’elle ne peut fournir. Elle ne rend pas l’exécution de scripts « sûre », en fait c’est seulement un ensemble prédéfini de directives de configuration.

Il est préférable de ne pas utiliser cette option, et de sécuriser les scripts pendant leur développement.

Les options safe_mode_* ne fonctionnent pas si safe_mode est désactivé.

Configuration recommandée :

• Développement : Off ;
• Production : Off.

disable_functions permet de désactiver certaines fonctions dans l’ensemble des scripts PHP. De nombreux hébergeurs mutualisés désactivent par exemple « exec » et « dl », pour ne citer que deux exemples.

disable_classes fonctionne sur le même principe, mais pour des classes.

Bien que 30 secondes soit un temps extrêmement long pour un script PHP (dont le temps moyen d’exécution ne dépasse pas 1 seconde), l’option max_execution_time est souvent laissée à sa valeur par défaut de 30 secondes. Cela n’influe pas véritablement sur les performances des scripts, mais réduire cette valeur permet de savoir plus rapidement si un script tourne en rond. La très large majorité des applications n’arrivent pas à timeout, et celles qui y arrivent ont probablement besoin d’une valeur spécifique précisée au niveau du script.

La fonction PHP set_time_limit() permet de modifier cette option pendant l’exécution d’un script.

On peut noter que le temps d’exécution d’un script ne compte que l’exécution du script : tout envoi de requête à un SGBD par exemple, ne compte pas dans l’intervalle défini par cette option. Seul le code PHP est pris en compte.

L’option max_input_time est son équivalent pour le traitement de données par formulaire. La valeur par défaut de 60 secondes me semble exagérée, mais là aussi elle n’a que peu d’influence sur le comportement de PHP.

Cette option est importante en fonction des extensions que votre serveur utilise. Plus vous utilisez de traitements complexes, plus vous aurez besoin d’augmenter cette valeur. Par exemple, si vous utilisez des traitements graphiques avec la bibliothèque GD ou similaire, il est probable que vous ayez besoin de l’augmenter.

Personne ne peut vous dire quelle est la configuration recommandée. Tout dépend des capacités de votre serveur, de la consommation de vos scripts, des données d’entrée, etc.

Définit quelles erreurs doivent être rapportées par PHP. Les erreurs sont habituellement affichées dans la sortie standard et enregistrées dans un fichier de log. Comme nous le verrons ailleurs dans ce cours, PHP dispose de divers niveaux d’erreur : c’est ce niveau d’erreur qui est choisi par l’option error_reporting. Un niveau élevé permet de connaître plus facilement les erreurs des scripts, donc les bugs ou encore les failles de sécurité.

Depuis PHP 5, E_STRICT permet de connaître certaines bonnes pratiques de programmation. Il faut donc utiliser E_ALL | E_STRICT pour avoir toutes les erreurs.

E_STRICT est intégré à E_ALL à partir de PHP 5.3, mais un nouveau niveau d’erreurs E_DEPRECATED est apparu dans le même temps. Depuis PHP 5.3, pour afficher toutes les erreurs il faut donc utiliser E_ALL | E_DEPRECATED.

Voici les niveaux d’erreur fréquemment utilisés :

error_reporting = E_ALL | E_STRICT

error_reporting = E_ALL | E_DEPRECATED

Configuration recommandée :

• Développement : le maximum possible ;
• Production : le maximum possible.

Cette option est malheureusement très souvent méprise pour la précédente, error_reporting. Ces deux directives ont pourtant des objectifs bien différents : error_reporting définit le niveau d’erreur qui doit être filtré par PHP (donc également dans les fichiers de log du serveur), tandis que display_errors définit si PHP doit afficher les erreurs dans la sortie standard, indépendamment du niveau d’error_reporting.

Afficher les erreurs internes de vos scripts à l’utilisateur final lui donne des informations précieuses sur le fonctionnement et les bugs, donc les failles, de vos scripts. Afficher les erreurs est une invitation à se faire pirater. PHP offre un moyen d’enregistrer les erreurs sans les afficher : le fichier de log.

Configuration recommandée :

• Développement : On ;
• Production : Off.

Comme le dit le fichier php.ini lui-même, cette option n’est utile que pour le débogage (donc dans de très rares cas), d’autant que de toute manière le fichier de log standard d’Apache indique les erreurs de chargement des extensions PHP.

Configuration recommandée :

• Développement : On ;
• Production : Off.

Il est évident que cette option devrait être laissée active dans toutes les situations. Sans fichier de log, vous n’auriez aucune idée des problèmes qui surviennent sur votre serveur, et vous n’auriez aucun moyen d’éviter leur récurrence.

Configuration recommandée :

• Développement : On ;
• Production : On.

Dans certaines situations, il peut être pratique d’ajouter de manière automatique une chaîne au début du message d’erreur. Par exemple pour les exceptions qui ne sont pas attrapées dans le code, j’ai tendance à demander l’affichage de « <pre> » afin d’améliorer la lisibilité du message.

Configuration recommandée :

• Développement :
  ;
• Production : Off.

Si vous ne souhaitez pas mixer les erreurs Apache et les erreurs PHP, cette option est pour vous. Attention aux droits d’accès au fichier de destination. Personnellement, j’ai tendance à ne pas activer cette option (ce qui est donc la configuration par défaut).

Voici une autre directive qui était censée apporter un confort d’utilisation, mais qui a été mal jugée et qui finalement a conduit à davantage de problèmes qu’elle aurait pu en régler.

Elle permet d’importer les variables autoglobales dans le scope du script, par exemple $_GET['page'] devient automatiquement $page. Le problème est que les programmeurs ne filtraient pas du tout ces variables, puisqu’elles étaient déjà dans le scope de leur application, et de nombreux problèmes de sécurité en ont découlé.

Certaines applications ont encore besoin de cette option. Si vous ne pouvez vraiment pas éviter d’utiliser l’une de ces applications, je vous recommande de ne pas activer register_autoglobals dans votre php.ini pour autant, mais plutôt d’utiliser httpd.conf ou .htaccess pour définir une configuration particulière pour le script qui a besoin des autoglobales.

Configuration recommandée :

• Développement : Off ;
• Production : Off.

Taille maximum des données que PHP accepte depuis un formulaire POST.

Apparues dans la même période que safe_mode, les directives magic_quotes_* sont tout aussi dangereuses. Elles donnent un faux sentiment de sécurité, car les données ne sont en rien protégées contre les attaques. Cette directive devrait disparaître de php.ini d’ici peu, il est donc fortement recommandé de ne plus l’utiliser et de réécrire les scripts qui en ont besoin.

Configuration recommandée :

• Développement : Off ;
• Production : Off.

Le type de document par défaut envoyé par Apache au navigateur Web. Il est fortement recommandé de laisser cela à la valeur proposée, puisque la quasi-totalité des scripts du marché se reposent sur cette configuration. Modifier cette valeur peut vous poser bien des ennuis.

Configuration recommandée :

• Développement : « text/html » ;
• Production : « text/html ».

L’encodage par défaut transmis par le serveur Web.

Là aussi, je vous recommande de ne pas modifier la configuration par défaut (option désactivée), car cela peut causer des problèmes avec certains scripts existants. Par contre, comme nous le verrons plus loin, il est souhaitable de modifier cette valeur dans tous les scripts PHP.

Utile pour simplifier vos appels à require() ou include() dans vos scripts.

Le répertoire vers vos extensions PHP. Préférez un chemin absolu et sans caractères spéciaux (espaces compris).

Autorise le chargement dynamique d’extensions PHP au moyen de la fonction dl(). Peut être très dangereux si vous autorisez l’exécution de code par d’autres développeurs puisque cette option vous retire la maîtrise des applications binaires disponibles sur votre propre machine.

Configuration recommandée :

• Développement : Off ;
• Production : Off.

Taille maximum des fichiers que PHP accepte depuis un formulaire POST. Cette valeur correspond à ce qui devrait apparaître dans le champ MAX_INPUT_SIZE de chacun de ces formulaires. Comme toujours, réduisez cette valeur au minimum, puis augmentez au niveau du répertoire (grâce au httpd.conf ou à un .htaccess) s’il y a besoin de plus.

allow_url_fopen permet d’utiliser simplement les fichiers situés sur d’autres serveurs Web, mais il faut bien entendu faire attention à traiter ce qu’ils contiennent avec beaucoup de prudence.

allow_url_include permet d’inclure du code provenant d’un autre serveur, comme si c’était un script local. Cette technique est vivement déconseillée, car vous n’avez pas la maîtrise du contenu de scripts distants, ce qui est donc très dangereux pour la sécurité de votre serveur. De plus, inclure un script distant a un effet dramatique sur les performances.

• date.timezone : Cette option est utilisée pour localiser le serveur dans le monde et pour adapter la valeur de retour de certaines fonctions de dates. Cette valeur devrait être mise par défaut selon votre fuseau horaire, par exemple à « Europe/Paris » si votre serveur est en France, et adaptée au moment de l’exécution de chaque script selon la localisation géographique de l’internaute.

Windows :

• SMTP (PHP_INI_ALL) : L’adresse du serveur SMTP à utiliser, typiquement votre hébergeur ou votre machine.
• smtp_port (PHP_INI_ALL) : 25 par défaut ;
• sendmail_from (facultatif - PHP_INI_ALL) : Adresse par défaut en tant qu’émetteur des e-mails.

Unix :

• sendmail_path (facultatif - PHP_INI_SYSTEM) : Chemin jusqu’au programme d’envoi d’e-mails, peut contenir des paramètres (par défaut : « sendmail -t -i »).

• session.save_handler (PHP_INI_ALL) : Par défaut « files », peut être modifié dans le script avec un appel à session_set_save_handler() ;
• session.save_path (PHP_INI_ALL) : Chemin vers le magasin des sessions, cf. ci-dessous pour des exemples ;
• session.use_cookies (PHP_INI_ALL) : Doit être activé pour utiliser la transmission par cookie, ce qui est la méthode conseillée ;
• session.name (PHP_INI_ALL) : Le nom de la variable de session, qui est aussi le nom du cookie, par défaut « PHPSESSID » ;
• session.auto_start (PHP_INI_ALL) : Démarrer la session à chaque requête ;
• session.cookie_lifetime (PHP_INI_ALL) : Habituellement laissé à sa valeur par défaut, c’est-à-dire zéro ;
• session.cookie_path (PHP_INI_ALL) : Généralement laissée à la valeur par défaut, qui correspond à la racine « / » du site Web ;
• session.cookie_domain (PHP_INI_ALL) : Doit correspondre au domaine hébergeant l’application, par exemple exemple.com ou .exemple.com pour inclure les sous-domaines ;
• session.cookie_httponly (PHP_INI_ALL) : Activer ce flag augmente la sécurité, mais interdit l’utilisation de la session par AJAX ;
• session.hash_function (PHP_INI_ALL) : « 0 » pour MD5, ou « 1 » pour SHA-1 (conseillé) ;
• url_rewriter.tags (PHP_INI_ALL) : Utilisé si vous transmettez l’ID de session par URL.

Exemples pour session.save_path :

session.save_path = "/path"

session.save_path = "N;/path"

session.save_path = "N;MODE;/path"

• tidy.clean_output (PHP_INI_PERDIR) : Activer ou désactiver le nettoyage automatique : ne pas utiliser cette option si vous n’avez pas que du contenu HTML (par exemple des images, PDF, etc.) ; il peut être intéressant de l’activer au niveau de chaque script.