2016

Un fichier .inc contient le même genre de code qu'un fichier .php. Cependant, par convention, on utilise l'extension .inc pour indiquer qu'il ne s'agit pas d'une page Web mais plutôt d'un fichier non autonome, qui sera INClus dans un autre. On pourrait par exemple avoir un fichier .inc qui contient l'information à placer au début de chaque page Web du site, un autre fichier .inc qui contient les information à placer à la fin de chacune des pages, etc.

Normalement, un fichier .inc devrait par défaut jouir des mêmes protections qu'un fichier .php. Les configurations du serveur peuvent cependant offrir des protections différentes.

Pendant le débogage d'un programme, plutôt que d'utiliser un débogueur, nous choisissons parfois d'afficher une variable à l'écran pour vérifier sa valeur. Mais pour nous assurer que cet affichage ne pourra pas avoir lieu lorsque le site sera en production (en cas où on oublierait d'effacer l'instruction qui l'affiche), nous utilisons notre fonction maison echo_debug().

Il serait intéressant d'appliquer la même logique aux messages d'erreur générés par PHP. En effet, lorsqu'un programme PHP rencontre du code pour lequel il a un message à envoyer, comme par exemple une erreur fatale, un avertissement ou l'utilisation d'une fonction obsolète, le message est automatiquement affiché à l'écran. Ce comportement est très pratique pendant la phase de développement. Cependant, une fois le site en production, ces messages peuvent ouvrir des trous de sécurité puisque le nom et le chemin du fichier concerné sont affichés.

Plusieurs techniques permettent d'effectuer des requêtes MySQL avec PHP. Prenons l'extension MySQLi. Elle permet notamment d'effectuer une requête à l'aide de $mysqli‑>query() ou, pour plus de sécurité, à l'aide de $mysqli‑>prepare(). Mais si $mysqli‑>prepare() est plus sécuritaire, doit-on pour autant éviter d'utiliser $mysqli‑>query() ?

En tant que développeur Web, vous devez être au courant des attaques qui pourraient être menées contre les sites que vous développez. Ceci vous permettra de mieux protéger votre code et vos données.

Cet article vous présente trois types d'attaques : les injections SQL, les attaques XSS et les attaques CSRF. Soyez avisé qu'il existe de nombreux autres types d'attaques. Ceci ne constitue qu'un minimum à connaître. De plus, les descriptions et exemples présentés ici ne constituent qu'une partie des techniques mises en place par les utilisateurs malveillants.

À l'aide de codes HTML ou Unicode, il est possible d'ajouter différents caractères spéciaux afin de répondre à un besoin précis ou encore pour agrémenter vos pages Web.

Voici quelques codes qui pourraient vous être utiles dans plusieurs contextes.

La validation d'un formulaire Web est une tâche complexe. Il faut en effet s'assurer que les données entrées par l'usager correspondent au format attendu, qu'elles soient valables et qu'elles ne compromettent pas la sécurité du site Web.

Normalement, une fois que l'usager a cliqué sur le bouton de soumission, les données entrées devraient être valides puisque la validation a déjà été effectuée côté client. Cependant, comme cette validation peut être désactivée, il est absolument nécessaire de refaire la validation côté serveur.

Voici les étapes permettant de bien valider les données d'un formulaire avec PHP.

La validation d'un formulaire Web côté client est essentielle. C'est elle qui permet d'informer l'usager le plus rapidement lorsqu'il entre des informations invalides.

En fait, les éléments visuels devraient déjà avoir averti l'usager de certaines règles à suivre : astérisque (*) devant les informations obligatoires, texte indiquant le format attendu, taille des zones de texte pour indiquer la taille de ce qui est attendu, etc. Mais ces éléments visuels ne sont qu'indicatifs. Ils n'effectuent pas de validation.

La validation côté client peut être effectuée à l'aide d'attributs HTML ou à l'aide de JavaScript, avec ou sans jQuery.

Certaines pages Web pourront jouer un double rôle :

• La première fois que la page est affichée, on affiche le formulaire.
• Après que le bouton de soumission ait été cliqué, on traite le formulaire.

Cet article vous expose une technique intéressante pour y parvenir.

Cet article a été déménagé : https://apical.xyz/fiches/la_validation_d_un_formulaire_web_002/Les_conversions_et_verifications_de_type

Généralement, dans les entreprises spécialisées en Web, un graphiste se chargera de créer la maquette qui répondra aux besoins du client. On dira que le graphiste développe une maquette « maison », c'est-à-dire une maquette bâtie de toute pièces par le graphiste.

Dans le cas où le site Web est développé par une seule personne ou par un groupe restreint de développeurs, trois options sont possibles :

• Si le développeur possède des talents de graphisme, bâtir lui-même une maquette maison;
• Retenir les services d'un graphiste à la pige pour développer une maquette maison;
• Utiliser une maquette tirée d'une banque de maquettes, gratuite ou payante.