Skip to main content

Réglages courants de WampServer

Les réglages ci-dessous sont courants pour une installation de Wamp Server toute fraîche.

Changer le répertoire root du serveur

C’est le répertoire qui s’affiche lorsqu’on lance Wamp et que l’on va sur localhost (ou 127.0.0.1) dans son navigateur. Par défaut, c’est le dossier /www du répertoire d’installation de Wamp.

Éditer le fichier C:\Program Files\Wamp\bin\apache\apachex.y.z\conf\httpd.conf et modifier la directive DocumentRoot pour la faire pointer vers le répertoire choisi. De plus, il faut également modifier quelques lignes en-dessous le chemin dans la balise <Directory>.

Envoyer des mails

Il vous faudra pour cela le programme Fake Sendmail (à extraire dans un dossier sendmail du répertoire d’installation, par défaut C:\wamp).

Ouvrir votre fichier php.ini (par défaut dans C:\wamp\bin\apache\apacheX.Y.Z\bin) et chercher l’option sendmail_path. La décommenter (enlever le point-virgule au début) et ajouter le chemin vers sendmail, comme suit :

sendmail_path = "C:\wamp\sendmail\sendmail.exe -t"

Enregistrer et fermer le fichier, puis redémarrer Wamp Server.

Il vous faudra ensuite écrire le code permettant d’envoyer un email. En PHP, je passe par la librairie PHPMailer. Télécharger la dernière version, puis récupérer les fichiers suivants (pas besoin des autres fichiers pour une simple fonctionnalité d’envoi d’emails) :

Cette librairie PHP est très populaire, et beaucoup de développeurs l’incluent dans leur projet pour sa simplicité. De ce fait, elle constitue une cible de choix pour les pirates : plusieurs vulnérabilités ont été découvertes par le passé, corrigées immédiatement par la communauté de développement très active sur ce projet. Il faudra donc bien veiller à la mettre à jour régulièrement, simplement en téléchargeant les nouveaux fichiers et en les extrayant à la place des anciens. Vous pouvez d’ailleurs écrire un petit script à cette fin.

Placez les fichiers dans un même dossier de votre projet, incluez le fichier PHPMailerAutoload.php (et seulement celui-ci), puis écrivez une fonction d’envoi d’emails.

Voilà la fonction d’envoi d’emails que j’utilise ; pas parfaite, mais elle convient à mes besoins.

// Constantes
define("EXPEDITEUR_NOM", "Vous");
define("EXPEDITEUR_ADRESSE", "noreply@votredomaine.tld");

// Permet de déterminer si on est en dev ou en prod
if($_SERVER['HTTP_HOST'] == 'votredomaine.tld'){
	define('ENV', 'prod');
	define("SMTP_HOST", "127.0.0.1");
	define("SMTP_PORT", "25");
	define("SMTP_USERNAME", "");
	define("SMTP_PASSWORD", "");
}
else {
	define('ENV', 'dev');
	define("SMTP_HOST", "127.0.0.1");
	define("SMTP_PORT", "25");
	define("SMTP_USERNAME", "");
	define("SMTP_PASSWORD", "");
}

// La fonction en tant que telle
// Remarque : $to peut être une adresse email ou un Array d'adresses email
function send_mail($to, $sujet, $message, $fromName, $fromEmail){
	$mail = new PHPMailer;
	$mail->setLanguage('fr', 'phpmailer.lang-fr.php');
	$mail->isSMTP();
    $mail->XMailer = ' ';
    $mail->Port = SMTP_PORT;
    $mail->Host = SMTP_HOST;

    if(ENV == 'dev'){
        $mail->SMTPDebug = 3;
        $mail->SMTPAuth = false;
    }
    else {
        $mail->SMTPDebug = 0;
        $mail->SMTPSecure = 'tls';
        $mail->SMTPAuth = true;
        $mail->Username = SMTP_USERNAME;
		$mail->Password = SMTP_PASSWORD;
    }

	$mail->AddReplyTo($fromEmail, $fromName);
	$mail->From = EXPEDITEUR_ADRESSE;
	$mail->FromName = EXPEDITEUR_NOM;

	if(gettype($to) == 'array'){
		foreach($to as $adresse){
			$mail->AddBCC($adresse);
		}
	}
	else {
		$mail->addAddress($to);
	}

	$mail->WordWrap = 50;
	$mail->isHTML(true);

	$mail->Subject = "=?utf-8?b?".base64_encode($sujet)."?=";
	$mail->Body = $message;

	if($mail->send()) {
		return true;
	}
	else {
		return $mail->ErrorInfo;
	}
}

J’utilise une petite condition au début pour savoir si on est en environnement de dev ou de prod. Vous pouvez ainsi avoir des réglages SMTP différents selon l’environnement. Pour la configuration que je vous propose dans cet article, c’est à dire en travaillant en local sur votre machine Windows, il faut laisser le serveur à 127.0.0.1 sur le port 25 en local. Pour votre environnement de prod, c’est à vous de régler les paramètres.

Pour finir, afin de recevoir les emails, je vous propose le très pratique Papercut qui émulera un serveur mail sur votre ordinateur. Lorsque vous enverrez des emails depuis votre application web en développement, ceux-ci seront reçus par Papercut. Ainsi, vous n’aurez pas besoin de dépendre d’un service externe. Il suffit simplement d’installer et lancer ce logiciel pour l’utiliser :

Dernière astuce pour les emails : je vous conseille d’utiliser ce template d’email HTML. Il est simple, propre, et fonctionne dans tous les webmails et logiciels, desktop et mobile.

Rendre accessible Wamp sur votre réseau local

Par défaut, vous ne pouvez pas accéder à votre serveur Wamp depuis une autre machine. Pourtant, cela peut être utile pour tester son application ou son site web depuis une autre configuration (résolution différente, test sur mobile…).

Pour cela, ouvrir le fichier httpd.conf (par défaut dans C:\wamp\bin\apache\apacheX.Y.Z\conf) et chercher l’expression Require local (chez moi, autour des lignes 280). Cette instruction autorise votre propre PC. Sur la ligne du dessous, ajoutez alors :

Require ip a.b.c.d

où a.b.c.d est l’adresse IP du PC que vous souhaitez autoriser. Si vous le souhaitez, vous pouvez également écrire seulement les premiers octets de l’adresse IP afin d’autoriser tout votre réseau local, ou utiliser la notation CIDR :

Require ip a.b.c
Require ip a.b.c.0/24

La plupart du temps, votre réseau local sera 192.168.0.0/24. Toutefois, vérifiez bien sur quelle réseau vous vous trouvez à l’aide de la commande ipconfig sur Windows ou ifconfig sur Linux.

Attention, cette astuce est valable pour la version 2.4+ de WampServer, qui utilise Apache 2.4.x au minimum. Pour les versions antérieures, il y a une autre syntaxe. Profitez-en pour mettre à jour WampServer, ça fait pas de mal !

Enregistrer et fermer le fichier, puis redémarrer Wamp Server.

Configurer cURL pour le HTTPS

Si vous avez à utiliser cURL pour récupérer du contenu depuis d’autres sites web, vous avez sans doute eu des petits soucis pour joindre les sites en HTTPS. En effet cURL pour fonctionner a besoin de savoir à quels certificats ils peut faire confiance. Or par défaut, aucune configuration n’est faite, cURL ne fait donc confiance à aucune connexion HTTPS et on se retrouve bien embêté.

Beaucoup de solutions sur Internet préconisent d’utiliser les options CURLOPT_SSL_VERIFYPEER à false ou encore CURLOPT_SSL_VERIFYHOST à 0, mais c’est une très mauvaise chose, car cela indique que cURL ne doit faire aucune vérification sur les certificats qu’ils rencontre. Aïe !

On va plutôt passer par la solution intelligente et installer la bibliothèque de certificats à qui cURL doit faire confiance. Pour cela, téléchargez le fichier cacert.pem depuis le site officiel de cURL, puis placez-le où vous le souhaitez sur votre disque-dur (j’ai choisi de le mettre dans C:\wamp\bin\php). Ce fichier, mis régulièrement à jour, contient la base de certificats des autorités de certification (qui permettent de signer les certificats des sites web) que Mozilla intègre dans son navigateur Firefox.

Il faut ensuite dire à PHP d’utiliser cette bibliothèque de certificats. Pour cela, il faut éditer vos fichiers php.ini (c’est à dire, celui du dossier C:\wamp\bin\apache\apacheX.Y.Z et celui du dossier C:\wamp\bin\php\phpu.v.w) et rajouter ces options :

curl.cainfo = "C:/wamp/bin/php/cacert.pem"
openssl.cafile = "C:/wamp/bin/php/cacert.pem"

Vérifiez également que la ligne suivante est décommentée (pas de point-virgule au début) :

extension=php_openssl.dll

On termine en relançant tous les services de WampServer.

Installez une autre version de PHP, Apache ou phpMyAdmin

Si vous souhaitez installer une autre version de PHP sur WampServer (pour faire une mise à jour, ou alors parce que vous devez vous adapter aux contraintes de l’environnement de production de votre société), l’opération est assez simple. Prenons pour exemple PHP.

Commencez par télécharger la version de PHP depuis le site officiel. Prenez de préférence une version Thread Safe. Différentes versions de « VC » existent : elles dépendent de la version du package de Visual C++ installée sur votre ordinateur. Sauf contraintes, VC11 est un bon choix, car il sera vraisemblablement déjà installé sur votre ordinateur. Si vous avez un message d’erreur lors du lancement de Wamp à cause d’une DLL manquante, vous pouvez télécharger le package redistribuable de Visual C++ manquant ici.

Extrayez l’archive dans le répertoire d’installation de WampServer, sous-répertoire bin/php/phpX.Y.Z (X.Y.Z étant la version de PHP à installer). Allez dans le dossier de la version précédente de PHP (appelons-la U.V.W) préinstallée dans WampServer, et copiez les fichiers suivants :

  • php.ini
  • phpForApache.ini
  • wampserver.conf

Collez ces fichiers dans le répertoire de la nouvelle version de PHP. Ouvrez les fichiers .ini et remplacez la chaîne U.V.W (correspondant à l’ancienne version) par X.Y.Z (correspondant à la nouvelle version) avec un coup de Rechercher et remplacer.

Quittez puis relancez WampServer. Cliquez sur l’icône près de l’horloge avec le bouton gauche, allez dans PHP, Version, puis sélectionnez la version que vous venez d’installer. WampServer recharge les paramètres, et c’est tout bon !

Pour Apache, télécharger votre version ici et copier les fichiers :

  • conf/httpd.conf
  • conf/extra/httpd-vhosts.conf
  • wampserver.conf

Pour phpMyadmin, télécharger votre version ici et copier les fichiers :

  • config.inc.php

Attention, phpMyAdmin s’installe dans apps/ et non dans bin/. De plus, vous devrez modifier le fichier alias/phpmyadmin.conf et wampmanager.conf de WampServer pour y rechercher et remplacer le numéro de version de phpMyAdmin.

N’oubliez pas d’éditer les fichiers copiés et rechercher/remplacer les numéros de version.

Je vous invite à considérer les deux alternatives suivantes, respectivement à MySQL et phpMyAdmin : MariaDB (qui est open source) et SQL Buddy (qui fait moins usine à gaz). Ils s’installent et s’utilisent de la même façon que MySQL et phpMyAdmin.

Créer des vhosts

La création de virtual hosts vous permettra de gérer plus facilement votre environnement de travail si vous développez plusieurs projets à la fois.

Pour ajouter un virtual host, éditer le fichier C:\Program Files\Wamp\bin\apache\apachex.y.z\conf\extra\httpd-vhosts.conf. Ajouter un bloc tel que celui-ci :

<VirtualHost *:80>
    ServerAdmin VOTRE_ADRESSE_EMAIL
    DocumentRoot "CHEMIN_ABSOLU_VERS_DOSSIER_DE_DEV"
    ServerName NOM_DE_DOMAINE_SOUHAITE
    ErrorLog "logs/NOM_DE_DOMAINE_SOUHAITE.error.log"
    CustomLog "logs/NOM_DE_DOMAINE_SOUHAITE.access.log" common
</VirtualHost>

Bien sûr, ceci constitue simplement la base ; si vous souhaitez mettre en place le HTTPS (bien que l’intérêt soit limité sur un environnement de dev), vous pouvez remplacer le port 80 par le port 443, et ajouter les autres directives courantes pour la mise en place du HTTPS.

Quant au nom de domaine souhaité, vous pouvez indiquer ce que vous souhaitez. Généralement, on choisit NOM_PROJET.local, par exemple blog.local.

Nous allons maintenant éditer le fichier C:\Windows\System32\drivers\etc\hosts afin d’ajouter une entrée pour notre nom de domaine. Rajouter une ligne telle que celle-ci dans le fichier :

127.0.0.1 NOM_DE_DOMAINE_SOUHAITE

Ainsi, quand vous tenterez d’accéder à votre nom de domaine, votre ordinateur n’aura pas à effectuer de requête DNS : c’est votre ordinateur qui réceptionnera la requête, et Wamp qui la prendra en charge. Grâce au virtual host, Wamp saura dans quel dossier se trouvent les fichiers auxquels vous tentez d’accéder.

D’autres idées ?

Si vous avez d’autres suggestions pour étoffer cet article d’astuces concernant WampServer, n’hésitez pas à l’inscrire ou à poser une question dans les commentaires !

Lire la suite

La sécurité des formulaires PHP

Il est un domaine que l’on ne doit pas oublier lorsque l’on réalise des formulaires en PHP, c’est la sécurité. En effet, les formulaires sont très souvent liés à une adresse mail ou à une base de données ; il est donc judicieux de protéger ces éléments-clé d’un système d’information.

Loin d’être un guide absolu dans le domaine, cet article regroupera quelques bonnes pratiques pour sécuriser un formulaire que j’ai glanées au fil du web.

Choisir la méthode du formulaire

Le premier choix qui s’impose lors de la réalisation d’un formulaire, c’est la méthode de transmission des données d’une page à une autre. Il en existe deux : GET, et POST. Alors que la méthode GET transmet les variables récupérées dans un formulaire par l’URL, la méthode POST les transmet de façon masquée.

Il vous faudra donc choisir, au cas par cas, si les variables récupérées peuvent être affichées au visiteur dans l’URL, ou non. Notez que ce n’est pas parce que les variables sont transmises en POST qu’elles sont totalement invisibles, chiffrées ou sécurisées ; il reste possible de les afficher (ou plutôt, de les intercepter) avec des outils.

Les failles XSS (Cross Site Scripting)

Pour profiter d’une faille XSS, l’attaquant va tenter d’insérer un code (JavaScript, le plus souvent) dans un input d’un formulaire non protégé, ceci afin de modifier le fonctionnement de la page. Prenons le cas d’un forum ; un attaquant pourrait, en exploitant une faille XSS, faire en sorte de subtiliser le cookie de connexion de chaque utilisateur qui se connecterait à ce forum. Ou alors, rediriger tous les utilisateurs vers une page de connexion ressemblant trait pour trait à la charte graphique du forum, mais qui en fait ne servirait qu’à récupérer leurs identifiants de connexion.

Les injections SQL

Pour exécuter une injection SQL, l’attaquant va tenter d’insérer un code dans un input d’un formulaire non protégé qui est relié à une base de données. Ce code peut servir à supprimer tout ou partie de la base de données ! Mais dans le pire des cas, une injection SQL peut permettre d’outrepasser le système d’authentification d’un site, afin d’y entrer sans autorisation (et voir, d’y entrer avec les privilèges de l’administrateur).

Insertion dans une base de données

Pour être sûr que des attaquants n’exécutent pas des injections SQL sur notre base de données, nous devons protéger l’insertion d’une saisie utilisateur grâce aux fonctions :

  • mysql_real_escape_string() : échappe les caractères spéciaux (notamment ‘  » et NULL) par un antislashs ; étant donné que c’est une fonction de MySQL, vous aurez besoin de vous connecter à votre base avec un mysql_connect() avant de pouvoir l’utiliser
  • addslashes() : réalise la même chose que mysql_real_escape_string(), mais n’est à utiliser que si vous utilisez un type de base de donnée qui ne propose pas ce genre de fonction

Dans le cas où le site que vous développez ne requiert pas que les utilisateurs aient un jour à saisir du code informatique dans leurs messages, on peut utiliser la fonction strip_tags() afin de purement et simplement supprimer les balises de code HTML ou Javascript des messages des utilisateurs.

Affichage depuis une base de données (ou saisie utilisateur)

Trois fonctions s’offrent à nous pour éviter les attaques XSS. Avant de les utiliser, vous devrez vous demander si vous souhaitez que les utilisateurs puissent stocker du code source dans votre base, ou si vous considérez que rien de ce qui n’entre dans votre base n’a besoin d’être du code. Dans le cas d’un forum par exemple, un utilisateur peut légitimement poster un message avec du code sain (utilisez alors l’une des deux premières fonctions).

  • htmlspecialchars() : encode les caractères < > ‘  » & pour qu’ils soient affichés mais pas exécutés
  • htmlentities() : la même chose que htmlspecialchars(), à la différence qu’elle encode beaucoup plus de caractères ; par exemple, le symbole €, les lettres accentuées é à ù…
  • strip_tags() : supprime carrément toutes les balises contenant < et > qui ne seront pas affichées

Enfin, si vous souhaitez récupérer des données qui ont été insérées en étant protégées par htmlspecialchars(), htmlentities() ou addslashes(), il vous faudra utiliser respectivement htmlspecialchars_decode(), html_entity_decode() et stripslashes().

Exemple concret

Pour finir, voilà un exemple d’un formulaire, avec dessous, la partie « sécurisation » (remarque : ce code sera prochainement obsolète car PHP pousse à l’utilisation de la « PDO » ; voir mon commentaire plus bas pour un exemple d’utilisation) :

<form id="mon_formulaire" method="POST" action="formulaire.php">
	<input name=premier_champ type=text placeholder="Premier champ" required>
	<input name=second_champ type=number placeholder="Second champ" required>
<button type=submit name=envoi>Envoi</button>

<?php
if (isset($_POST['envoi']))
{
	// Connexion à la base de données
	mysql_connect($dbhost, $dbuser, $dbpass);
	mysql_select_db($dbname);
	
	// Sécurisation des données reçues
	$premier_champ = mysql_real_escape_string($premier_champ);
	$second_champ = mysql_real_escape_string($second_champ);
	
	// Création et envoi de la requête
	$sql = 'INSERT INTO ma_table VALUES("'.$premier_champ.'","'.$second_champ.'")'; 
	mysql_query ($sql) or die ('Erreur SQL !'.$sql.'<br />'.mysql_error());  
	
	//Clotûre de la connexion à la base de données.
	mysql_close (); 

	// Affichage des résultats à l'utilisateur
	echo 'Vous avez inséré '.htmlspecialchars($premier_champ).'.';
}
?>
</form>

Voilà donc quelques méthodes simples pour éviter que votre formulaire soit une passoire 🙂 n’hésitez pas à m’indiquer dans les commentaires si vous avez d’autres astuces pour la sécurisation simple des insertions et lectures de base de données.

XKCD - Exploits of a mom

Pour aller plus loin
StackOverflow – How to prevent code injection attacks in PHP (EN)
Webmaster Hub – Sécurité et formulaires PHP
Apprendre PHP – Traitement des formulaires
Chez Neg – Sécurité d’un formulaire PHP
Bastien Rossi – Les injections SQL
Le blog de maniT4c – Protection de formulaire contre les robots

Lire la suite

Vous utilisez Internet Explorer ? Laissez-moi vous taxer…

Un site de vente en ligne, Kogan, a eu l’excellente idée de faire payer à ses utilisateurs une taxe s’ils utilisent Internet Explorer 7 ! Celle-ci sert à couvrir les frais « engendrés par temps passé à adapter le site pour IE » (et au passage, à faire le buzz :-)).

Taxe pour les utilisateurs d'IE

En effet, quand on est développeur web, il relève parfois du cauchemar d’adapter les jolies petites choses permises par les avancées des langages de programmation web pour Internet Explorer, en particulier pour les vieilles versions. On s’aperçoit vite que ce qui rend bien dans Firefox, Chrome, Opera… passe souvent très mal dans IE : pas de bords arrondis, décalage complets, polices particulières non prises en compte…. rhaa ! IE ne respecte pas les standards du web.

C’est pourquoi, le site Kogan propose à ses utilisateurs dont « les administrateurs systèmes sont restés dans le coma pendant 5 ans » d’utiliser à la place un autre navigateur, récent et respectueux des standards (n’importe quel autre), afin d’éviter d’être taxé de plus de 6% de leur commande finale.

Pas bête ! Perso, j’affiche un gros bandeau rouge sur chaque page de mon site (pas ce blog) pour les utilisateurs qui utilisent IE (toutes versions, rien à foutre). Démo.

Lire la suite

Tester la présence d’AdBlock en Javascript

Je vais vous expliquer une petite technique toute simple en Javascript pour savoir si vos visiteurs utilisent un bloqueur de publicités dans leur navigateur tel que AdBlock.

Tout d’abord, mettez votre pub dans une DIV réservée à elle seule :

<div id="pub">
	<!-- Code de pub de votre régie publicitaire : AdSense, ClicManager... -->
</div>

Ensuite, insérez cette fonction Javascript dans votre header (nécessite jQuery) :

<script>
	function TestPub() {
		if ($("#pub").height() == 0){
			//Faites ce que vous voulez !
		}
	}
	$(TestPub);
</script>

À l’endroit indiqué, vous pouvez faire ce que vous voulez ! Vous pouvez insérer du texte, une image, ou si vous êtes vicieux, un alert()… Mais ne soyez pas trop méchants quand même ; j’utilise moi-même AdBlock, c’est vraiment pénible d’être pollué sur le Net. Webmasters, ne prenez pas vos visiteurs pour de la merde, mettez de la pub discrètement

Perso, voilà l’image que j’ai choisi d’insérer à la place de la pub : sobre, amusant, efficace.

Vous utilisez un bloqueur de pub type AdBlock. Bouh !

Vous devez mettre la ligne suivante pour afficher autre chose à la place de votre publicité.

document.getElementById("pub").innerHTML = "<p>Lorem ipsum</p>";

Quoi que vous décidiez de faire, gardez à l’esprit que les versions les plus récentes de ce genre de plugins permettent de bloquer non seulement les bandeaux de pub, mais également les div et sections de page. Du coup, même si vous mettez du texte à la place de la pub, il peut être bloqué !

AdBlock permet de bloquer des div entières
AdBlock sous Chrome permet de bloquer des div complètes

Lire la suite

Ajouter de la neige en JavaScript sur une page web

Si vous êtes webmaster, vous pourriez sans doute avoir envie de créer un petit effet « hivernal » sur votre site pour les fêtes de fin d’année. Un petit truc tout simple et bien sympathique consiste à implémenter un script Javascript pour faire tomber de la neige sur une page web.

Commencez par télécharger ce script sur vos pages web.

Cherchez ensuite une image de flocons (n’oubliez pas qu’il faut un fond transparent !) en PNG.

Remplacez les variables SNOW_Picture et SNOW_no (respectivement, l’adresse absolue de l’image que vous avez choisie, et le nombre de flocons par page) dans le script.

Copiez alors cette ligne sur chacune des pages où faire apparaître la neige (supprimez l’espace) :

< script type="text/javascript" src="http://www.votredomaine.com/js/snow.js">

Et si vous voulez voir la neige de Google, faites une recherche sur let it snow

Source du tutoriel : Peters1.dk

Lire la suite