La réécriture d’URL désigne le processus de modification d’une URL dans le but de la rendre plus facile et plus accessible aux internautes. Généralement, cette modification se produit pour rendre l’URL plus courte et cohérente. Ainsi, les utilisateurs s’en souviendront et n’auront aucun mal à lire ou à écrire en cas de besoin.

De nos jours, les internautes savent qu’il y a d’énormes risques sur internet. Et lorsque nous rencontrons une adresse URL de longue queue composée de chiffres et de lettres, nous avons tendance à nous en méfier.

C’est pourquoi il est important de garantir la confiance des visiteurs lorsqu’ils rencontrent votre adresse URL pour la première fois en la rendant courte et en lui donnant du sens.

Si vous n’arrivez toujours pas à mieux saisir le concept de réécriture d’URL, je vous invite à lire attentivement cet article.

Chapitre 1 : Qu’est-ce que la réécriture d’URL ?

Dans ce chapitre, nous allons essayer de clarifier les thèmes essentiels pour vous donner une idée claire de ce qu’on entend par réécriture d’URL.

1.1. Définition de réécriture d’URL

Presque tous les serveurs, que ce soit Apache, Nginx, IIS de Microsoft ou autres, s’offrent la possibilité de modifier les URL avant qu’elles ne soient visibles par les chercheurs.

Cette modification se produit généralement lorsqu’un document demandé se trouve ailleurs et le visiteur doit plutôt être redirigé vers le nouvel emplacement.

En plus de ces réécritures externes où un visiteur demande une URL et le serveur vérifie si certaines redirections s’appliquent à l’URL demandée, il existe également des réécritures internes.

Les serveurs peuvent rapidement reconnaître le document ou la ressource qui doit être mis à disposition dans une URL, quel que soit l’endroit où il est stocké dans la structure du dossier interne.

Lorsque nous prenons par exemple le cas de WordPress, chaque article de blog est stocké dans une base de données et se voit attribuer un identifiant. Les différentes pages peuvent toujours être demandées via cet ID.

1.2. Comment fonctionne la réécriture d’URL ?

La fonction de réécriture d’URL consiste à placer simplement une couche au-dessus de l’adresse d’origine et la transforme en quelque chose de facile à trouver et qui a du sens.

Du point de vue de l’utilisateur, après la réécriture, l’URL du site web reste la même dans le navigateur, mais plus cohérente. 

Mais dans les coulisses, le navigateur réécrit l’URL dans ce gâchis compliqué et envoie une requête aux serveurs.

Les réécritures d’URL sont également extrêmement utiles lorsque la structure du serveur est modifiée et que les ressources sont déplacées d’un dossier à un autre. 

Dans cette situation, un administrateur système écrira simplement la partie vers laquelle pointe l’URL conviviale. 

Fondamentalement, puisque la ressource a été déplacée, elle aura un emplacement différent. Par conséquent, une réécriture est nécessaire pour pointer l’URL réécrite vers le nouvel emplacement de la ressource. 

Cela ne doit pas être confondu avec les fonctions de redirection qui se produisent lorsqu’une ressource a été remplacée par une ressource différente.

1.3. Quelle est l’importance de réécrire une URL ?

Il est extrêmement important que les URL aient un sens et donnent une idée de la page à laquelle elles se réfèrent, tout en étant faciles à comprendre pour les moteurs de recherche.

La réécriture d’URL ne montre pas le fonctionnement interne et les statistiques derrière l’adresse d’un site web à l’utilisateur, l’empêchant de voir les chaînes de requête, ce qui ne s’avère pas bénéfique pour le site.

Ce processus n’est pas seulement utile pour ceux qui le consultent ou le lisent, mais contribue également à l’aspect sécurité du site en empêchant dans une large mesure le piratage ou l’accès à des utilisateurs malveillants. 

Il vise la création d’une URL riche en mots-clés, ce qui signifie inclure le mot-clé dans le texte de l’URL, ce qui aidera efficacement le processus de référencement. 

Cela permet de s’assurer que le site en cours de développement est déjà optimisé dans une certaine mesure avant même son lancement.

Les URL créées ont également tendance à masquer les liens, qui la plupart du temps semblent s’étaler longuement.

De plus, la même URL peut continuer à être utilisée, même s’il y a un changement dans le lien de départ.

Le processus de réécriture d’URL peut être effectué sur tout type de site ou de système de gestion de contenu web, qu’il s’agisse d’un site développé par asp.net ou de ceux créés à l’aide de la technologie PHP. 

Le processus de réécriture d’URL s’effectue en fonction des langages et des besoins des sites web. 

Cela semble être possible avec la technologie ASP.NET de manière efficace, du fait qu’elle est similaire à Internet Information Server (IIS). En fait, l’ASP.NET est un moteur de script côté serveur (IIS) qui produit des pages Web interactives.

La réécriture d’URL est également rendue possible avec PHP avec le module mod rewrite pour serveur Apache, entre autres.

De plus, ils semblent également être conviviaux via l’interface. Il est également utile si un utilisateur souhaite supprimer une section de l’URL afin de naviguer au niveau supérieur, ce qui s’avère très bénéfique pour lui.

Supposons qu’un utilisateur qui atterrisse sur la page exemple.com/seo/recritture-url et souhaite revenir à la l’accueil du site. Il pourra simplement garder exemple.com et supprimer les autres parties.

1.4. Pourquoi la réécriture d’URL est-elle bonne pour le référencement ?

L’utilisation d’une réécriture d’URL présente plusieurs avantages. D’une part, les réécritures d’URL aident à l’accessibilité et à l’amélioration de l’expérience utilisateur. 

En termes simples, lorsqu’un utilisateur regarde une URL dans un résultat de moteur de recherche, il n’a pas à chercher à comprendre de quoi parle cette page ou cet article.

De plus, les URL désordonnées n’encouragent pas les gens à cliquer dessus, ce qui peut  entraîner un taux de clic inférieur. Cette situation  est généralement mauvaise pour le référencement et la performance des sites.

Par ailleurs, les URL conviviales aident à optimiser le contenu pour le référencement. 

Une URL comprenant le titre de l’article et le mot-clé principal vous aidera avec votre indexation Google et la perception des bots de votre article ou page Web. 

En conséquence, les URL optimisées pour le référencement grâce à la réécriture d’URL entraînent une meilleure visibilité, une plus grande crédibilité auprès de vos utilisateurs et un volume de trafic naturellement plus élevé.

En dehors de cela, l’utilisation de réécriture d’URL permet également de maintenir la cohérence de votre chemin d’URL et de la structure de votre nom de page. 

Enfin, les réécritures contribuent également aux performances grâce à la mise en cache en mode utilisateur et au dépannage, car elles prennent en charge le suivi des demandes ayant échoué.

1.5. Réécriture d’URL Vs redirection

Contrairement aux réécritures d’URL, une redirection est une action côté client, pas côté serveur.

Fondamentalement, une réécriture se produit lorsque l’adresse de la ressource change, ou nous avons besoin d’une couche plus simple et plus conviviale. 

Cela se produit dans les coulisses et l’utilisateur n’en est pas conscient. En comparaison, une redirection se produit lorsque la ressource n’existe plus.  

Les redirections peuvent également se produire lorsque nous prédisons comment un utilisateur tentera d’accéder à une ressource et configurons des fonctions de redirection pour nous assurer qu’il accède correctement à la ressource.

Par exemple, la résolution WWW est une action de redirection par laquelle, quelle que soit la manière dont l’utilisateur recherche la page d’accueil de Twaino, il utilise le WWW. avant le nom de domaine ou non, ils atterriront toujours sur Twaino.com.

Chapitre 2 : Pourquoi est-il important de faire une réécriture d’URL ?

Ce chapitre est consacré aux raisons pour lesquelles les webmasters doivent faire une réécriture.

 2.1. Les applications doivent être sécurisées

Il est important que les webmasters protègent leurs sites web contre toutes sortes d’attaques. En effet, un particulier ne doit pouvoir être en mesure de nuire à votre site en modifiant une URL qui pointe vers vos applications. 

Afin d’assurer la sécurité de votre site, vérifiez toutes les variables GET provenant de vos visiteurs.

Par exemple, imaginons que nous ayons un script simple qui affiche tous les produits d’une catégorie. Généralement, ça se présente comme ceci:

• myapp.php?target=showproducts&categoryid=123

Mais lorsqu’un ScriptKiddie(tm) tape dans sa barre de navigation myapp.php?target=showproducts&categoryid=youarebeinghacked, de nombreux sites afficheront des messages d’erreur se plaignant de l’utilisation d’une mauvaise requête SQL, d’un ID de ressource MySQL invalide, etc. 

Cela montre simplement que ces sites ne sont pas du tout ou très bien sécurisés.

2.2. Les applications doivent être compatibles avec les moteurs de recherche

Ce n’est généralement pas connu, mais de nombreux moteurs de recherche n’indexeront pas votre site en profondeur s’il contient des liens vers des pages dynamiques comme celle mentionnée ci-dessus. 

Ils prennent simplement la partie ‘’nom’’ de l’URL. C’est-à-dire tout ce qui précède le point d’interrogation, qui contient les paramètres nécessaires au bon fonctionnement de la plupart des scripts, puis essaient de récupérer le contenu de la page. 

Pour que ce soit clair, voici quelques liens de notre page fictive :

• myapp.php?target=showproducts&categoryid=123 ;
• myapp.php?target=showproducts&categoryid=124 ;
• myapp.php?target=showproducts&categoryid=125.

Malheureusement, il y a de fortes chances que certains moteurs de recherche essaient de télécharger la page myapp.php.

Dans la plupart des cas, l’appel d’un script comme celui-ci provoque une erreur ou il n’affichera pas le contenu approprié vers lequel le lien pointait. 

Essayez simplement cette recherche sur google.com :

‘’vous avez une erreur dans votre syntaxe sql’’ .php -forum

Vous allez remarquer qu’il existe à la fois d’énormes erreurs et des menaces de sécurité dans les scripts répertoriés. 

2.3. Les applications doivent être conviviales

Si votre site web utilise une application comme :            

quehttp://www.downloadsite.com?category=34769845698752354, alors la plupart de vos visiteurs auront du mal à revenir à leur catégorie préférée à chaque fois qu’ils partent de la page principale de votre site. 

Il est encore plus facile pour l’utilisateur de trouver l’URL dans la liste déroulante des navigateurs lorsqu’il tape dans le champ ‘’Emplacement’’, bien que cela ne fonctionne bien sûr que si l’utilisateur l’a déjà visité auparavant.

Chapitre 3 : Quelles sont les règles de réécriture d’URL ?

Il est évident que la réécriture d’URL est une opportunité pour les sites de rendre leurs URL conviviales. Cependant, cette pratique doit respecter certaines règles pour être efficace et produire des effets escomptés.

Nous aborderons dans ce chapitre ces règles qu’il faut respecter en vue de réécrire correctement les URL d’un site.

3.1. Comment réécrire une URL avec IIS ?

Pour réécrire une URL avec IIS, vous devez commencer par installer le logiciel téléchargeable sur la plateforme de Microsoft.

Une fois installé, vous verrez une nouvelle icône « Url Rewrite » dans la console de gestion IIS.

Etape 1 : La console de gestion IIS avec la réécriture d’URL ajoutée

Vous pouvez gérer la réécriture d’URL au niveau du serveur ou pour des sites individuels comme bon vous semble. 

Grâce au module de réécriture d’URL, vous verrez les ‘’modèles’’ utilisés. Les modèles sont dans l’un des trois modes suivants : 

• Correspondance exacte ; 
• Caractères génériques ;
• Et expressions régulières ECMAScript, qui sont des expressions régulières compatibles Perl.

Il existe deux types de règles : entrantes et sortantes. 

Les règles entrantes examinent les URL de demande et les modifient. Tandis que les règles sortantes inspectent le trafic envoyé, recherchent les URL qu’il contient et les réécrivent si nécessaire ;

C’est encore plus intéressant lorsque le contenu peut utiliser une URL absolue qui n’est pas celle que l’utilisateur devrait recevoir ;

L’un des avantages de la réécriture d’URL est qu’elle prend en charge un certain nombre de règles intégrées différentes  qui facilitent la vie lorsque vous souhaitez effectuer une réécriture commune. 

La liste complète des règles intégrées est :

• Règle avec carte de réécriture : permet de définir un ensemble de chemins et leurs remplacements sous la forme d’une simple liste ;
• Blocage des requêtes : Interdire l’accès à un chemin ;
• URL conviviale : Crée rapidement des règles pour mapper les segments de chemin aux chaînes de requête  ;
• Reverse Proxy : Permet au serveur actuel d’inverser le proxy d’un autre ;
• Appliquer les URL en minuscules : Cela oblige le client à toujours utiliser des URL en minuscules via une redirection HTTP de statut 301 ‘’Permanent’’ ;
• Nom de domaine canonique : Utilise une redirection HTTP de statut 301 ‘’Permanent’’ pour s’assurer que les clients utilisent toujours le nom de domaine spécifié ;
• Ajouter ou supprimer le symbole de barre oblique de fin : Cela ajoutera ou supprimera toujours la barre oblique de fin dans un chemin d’URL à l’aide d’une redirection de statut HTTP 301 ‘’Permanent’’.

Etape 2 : La création d’une règle vous permet de choisir une règle intégrée à partir de laquelle commencer

Les règles intégrées sont excellentes, car bien qu’elles soient accompagnées d’un assistant personnalisé, le cas échéant, elles génèrent des règles standards que vous pouvez ensuite ajuster ou modifier selon vos besoins.

La règle d’URL conviviale est assez populaire pour ceux qui n’ont pas de système qui le fait automatiquement. 

Vous commencez par entrer un exemple de l’URL ‘’laide’’ dont le site a réellement besoin. 

Etape 3 : Création d’une règle d’URL conviviale

Une autre des règles intégrées que la plupart utilisent est la règle du proxy inverse. 

Encore une fois, le système vous guide à travers une configuration par défaut compétente dans ce qui pourrait être une tâche très complexe. 

Il contient des options intégrées et modifiables  telles que :

• Si les réponses HTTPS doivent toujours être transmises par proxy au HTTP standard ;
• Si vous souhaitez ou non utiliser une règle sortante pour masquer le nom du serveur interne. 

Les gens l’utilisent souvent pour pouvoir configurer un serveur central avec des hôtes web virtuels sur la même adresse IP pour gérer les demandes entrantes qui doivent être envoyées à différents serveurs internes.

Figure D : Création d’un proxy inverse

La dernière règle dont nous allons discuter concerne les cartes de réécriture. 

Celles-ci vous permettent de créer une liste d’URL et de les traduire en URL de substitution. 

En soi, une carte de réécriture est inutile, elle doit être utilisée dans le cadre d’une règle plus large à la place ou en conjonction avec les modèles de substitution. 

Celles-ci sont particulièrement utiles lorsque vous concevez ou réorganisez un site qui utilise des URL non prévisibles. 

En combinant une redirection utilisant le statut HTTP 301 ‘’Permanent’’ avec une carte de réécriture, vous pouvez personnaliser vos traductions dans les situations où les règles ne fonctionnent pas bien.

Une fois que vous avez configuré la règle de base, vous pouvez la modifier si nécessaire. L’éditeur de règles décompose vraiment bien les choses. 

Vous commencez avec un nom de règle et le modèle d’URL à faire correspondre. 

À partir de là, vous pouvez ajouter diverses conditions, telles que :

• La recherche d’une chaîne particulière dans un paramètre de l’URL ; 
• Une variable d’environnement de serveur ; 
• Etc. 

Vous pouvez lui dire de correspondre à toutes ou à n’importe quelle des conditions. Si les conditions ne sont pas remplies, la règle n’effectuera pas la réécriture. 

Vous pouvez également effectuer des substitutions sur des variables de serveur, ce qui est idéal pour appliquer certains comportements. 

Les variables de serveur englobent une très grande liste d’éléments avec lesquels travailler, y compris les cartes de réécriture que vous avez créées. 

Ensuite, vous définissez ce que la règle doit réellement faire, c’est-à-dire effectuer une réécriture ou une redirection qui enverra en fait un code d’état HTTP de redirection au client pour qu’il interroge la nouvelle URL. 

Ensuite, vous définissez le modèle pour la réécriture elle-même. Enfin, vous avez quelques options :

• Ajout de la chaîne de requête ;
• Enregistrement de la demande ;
• Ne plus exécuter de règles une fois celle-ci terminée.

3.2. Comment réécrire une URL avec Apache ?

Voici en quelques étapes comment vous pouvez définir les règles de réécriture d’URL avec Apach :

Étape 1 : Installer le serveur Web Apache

Avant de commencer, assurez-vous que le package de serveur Web Apache est installé sur votre système. S’il n’est pas installé, vous pouvez l’installer avec la commande suivante : ‘’apt-get install apache2 -y’’

Une fois le package installé, démarrez le service Apache avec la commande suivante : ‘’systemctl demarrer apache2’’.

Ensuite, ouvrez votre navigateur Web et tapez l’URL http://your-server-ip pour vérifier le serveur Web Apache. 

Étape 2 : Activer mod_rewrite

Par défaut, le module mod_rewrite est installé avec le package Apache, mais il est désactivé. Vous devrez donc d’abord l’activer.

Vous pouvez l’activer avec la commande suivante : ‘’a2enmod réécriture’’.

Ensuite, redémarrez le service Apache pour appliquer les modifications et vérifier le module Apache mod_rewrite avec la commande suivante : apache2ctl -M | grep rewrite_module.

Vous devriez obtenir la sortie suivante : rewrite_module (partagé)

Étape 3 : Activer les fichiers .htaccess

Vous pouvez configurer des règles de réécriture directement dans le fichier de configuration principal d’Apache. Cependant, il est recommandé d’écrire des règles dans le fichier .htaccess à l’intérieur de chaque site Web.

Par défaut, Apache ne permet pas d’utiliser le fichier .htaccess. Vous devrez donc activer le fichier .htaccess dans votre fichier de configuration d’hôte virtuel par défaut.

Pour ce faire, modifiez le fichier de configuration de l’hôte virtuel par défaut d’Apache : nano /etc/apache2/sites-available/000-default.conf.

Ajoutez les lignes suivantes avant la ligne : 

<Répertoire /var/www/html>

        Options Index FollowSymLinks MultiViews

        Autoriser tout remplacer

        Exiger que tout soit accordé

</Répertoire>

Assurez-vous d’enregistrer et de fermer le fichier, puis redémarrez le service Apache pour appliquer les modifications : systemctl redémarre apache2.

Étape 4 : Configurer les réécritures d’URL

Pour comprendre comment fonctionnent les réécritures d’URL, nous allons créer une page home.html dans le répertoire racine du document Apache. 

Nous allons ensuite configurer une réécriture d’URL de base qui permettra d’accéder à la page http://your-server-ip/home et de la convertir en chemin de page réel http://your-server-ip/home.html.

Commençons par créer une page home.html :

nano /var/www/html/home.html

Ajoutez le contenu suivant :

<html>

    <tête>

        <title>Accueil</title>

    </head>

    <corps>

        <h1>Page d’accueil</h1>

<h2>Voici ma page d’accueil</h2>

    </body>

</html>

Enregistrez et fermez le fichier lorsque vous avez terminé.

Ensuite, créez un fichier .htaccess dans le répertoire racine du document par défaut du site Web pour tester mod_rewrite.

nano /var/www/html/.htaccess

Tout d’abord, ajoutez la ligne suivante pour activer le moteur de réécriture : RewriteEngine activé.

Ensuite, ajoutez la règle de réécriture suivante qui redirige les visiteurs vers home.html s’ils demandent la page http://your-server-ip/home : RewriteRule ^home$ home.html [NC].

Enregistrez et fermez le fichier lorsque vous avez terminé.

Une brève explication de la syntaxe des règles de réécriture est présentée ci-dessous :

• ^ : Cela correspondra à tout texte après l’adresse IP du serveur ;
• $ : Ceci indique la fin de l’URL.
• home : Cela correspond à la chaîne réelle home ;
• home.html : Cela définit le fichier réel auquel le visiteur accède ;
• [NC] : Cela rend la règle insensible à la casse.

Vous pouvez maintenant visiter la page d’accueil à l’ adresse http://your-server-ip/home sur votre navigateur Web. Apache redirigera vers la page home.html.

 3.3. Comment faire une réécriture avec nginx

Dans nginx, la directive de réécriture peut être spécifiée dans l’un des trois contextes suivants : serveur, emplacement, si.

3.3.1. Exemple de réécriture Nginx utilisant $1, $2, ..

Voici un exemple de directive de réécriture Nginx : réécrire ^(/data/.*)/geek/(\w+)\.?.*$ $1/linux/$2.html last.

Par exemple :

Url/data/distro/geek/test.php sera réécrit comme url/data/distro/linux/test.html.

Dans cet exemple, lorsque vous appelez l’URL d’origine avec test.php depuis le navigateur, elle sera réécrite en fonction de la règle de réécriture ci-dessus et servira la page test.html de /data/distro/linux/

Dans la règle de réécriture ci-dessus :

• $1 et $2 capturent les chaînes appropriées à partir de l’URL d’origine qui ne change pas ;
• $1 dans la chaîne de remplacement correspondra à tout ce qui se trouve à l’intérieur de la 1ère parenthèse ( ) dans le reg-ex. Dans notre exemple, $1 est /data/ ;
• De même, $2 correspond à tout ce qui se trouve à l’intérieur de la 2ème parenthèse ( ) dans le reg-ex. Donc, $2 est (\w+), qui est n’importe quel mot qui vient après le /geek/ dans l’URL d’origine ;
• Dans notre exemple, $2 est un test last. Cet indicateur s’assurera d’arrêter la recherche de la directive de réécriture dans l’emplacement ou le bloc actuel et d’utiliser l’URL modifiée et de rechercher un nouvel emplacement pour toute autre directive de réécriture qui correspond ;
• *$ : Ceci indique l’extension dans l’URL d’origine. Veuillez noter qu’ici, l’extension de l’URL d’origine sera remplacée par .html dans l’URL réécrite. Ainsi, même si vous appelez .php dans l’URL d’origine, il ne servira que le fichier .html dans l’URL réécrite.

Bien que les règles de réécriture Nginx soient similaires à celles d’Apache, il existe encore de nombreuses différences dans la manière dont vous écrivez une règle de réécriture dans Nginx.

3.3.2. Création d’un fichier de contrôleur à l’aide de Nginx Rewrite

À l’aide de la réécriture, vous pouvez acheminer de nombreuses URL d’origine entrantes vers un modèle de contrôleur principal qui servira ces demandes.

L’exemple de réécriture suivant explique cela :

• réécrire ^/linux/(.*)$ /linux.php?distro=$1 dernier ;

Dans cet exemple, lorsque vous appelez l’URL thegeekstuff.com/linux/centos, elle sera réécrite en utilisant la règle ci-dessus et elle servira la page avec cette URL réécrite : 

• thegeekstuff.com/linux.php?distro=centos

Comme vous le voyez ci-dessus, toute URL qui correspond au modèle ici  /linux/ dans l’URL sera servie par linux.php, mais la dernière partie de l’URL entrante d’origine sera utilisée comme valeur pour l’argument de distribution dans le contrôleur linux.php.

Ainsi, la règle de réécriture ci-dessus transformera l’URL entrante comme suit :

• linux/centos devient linux.php?distro=centos ;
• linux/debian devient linux.php?distro=debian ;
• linux/redhat devient linux.php?distro=redhat ;
• etc.

Comme dans l’exemple précédent, nous utilisons $1 dans la chaîne de remplacement pour capturer tout ce qui se trouve à l’intérieur de la 1ère parenthèse ( ) dans le reg-ex. Dans ce cas, il s’agit de la dernière partie de l’URL entrante d’origine.

Nous utilisons également le dernier indicateur ici pour demander à nginx d’arrêter la recherche d’autres directives de réécriture dans le bloc actuel et de passer à l’emplacement correspondant suivant pour une recherche plus approfondie.

3.3.3. Réécrire l’indicateur de rupture dans le contexte de l’emplacement

Dans cet exemple, nous avons placé la condition de réécriture dans la directive location .

Dans cet exemple, la directive d’emplacement est /data/, qui correspond également au $1 dans la chaîne de remplacement donnée ci-dessous.

données de localisation/ {

    réécrire ^(/data/.*)/geek/(\w+)\.?.*$ $1/linux/$2.html break ;

    retour 403 ;

}

Voici ce qui se serait passé si vous aviez utilisé le drapeau « dernier » ci-dessus :

• Ainsi, si vous aviez ‘’last’’ comme indicateur, après la réécriture initiale de l’URL, Nginx recherchera généralement la prochaine directive de réécriture pour la nouvelle URL ;
• Dans ce cas, Nginx continuera à rediriger vers les mêmes données de localisation et continuera à traiter la même règle de réécriture au maximum 10 fois, et finalement il renverra le code d’erreur 500.

3.3.4. Ajout d’un point d’interrogation à la chaîne de remplacement Nginx Rewrite

Si une chaîne de remplacement inclut les nouveaux mots-clés de requête, les mots-clés de requête précédents sont ajoutés après eux. 

Si vous ne souhaitez pas adopter cette manière, placez un point d’interrogation à la fin d’une chaîne de remplacement pour éviter de les ajouter.

Dans l’exemple suivant, dans la portion de chaîne de remplacement, il n’y a pas de point d’interrogation à la fin. C’est-à-dire pas de point d’interrogation après 1 $ :

réécrire ^/linux/(.*)$ /linux.php?distro=$1 last ;

Dans l’exemple ci-dessus, lorsque la chaîne de remplacement inclut les arguments de la requête entrante, les arguments de la requête précédente se sont ajoutés après eux.

Lorsque vous ne voulez pas que cet ajout se produise vraiment, vous pouvez avoir une autre issue.

Dans l’exemple suivant, dans la partie chaîne de remplacement de la réécriture Nginx, vous pouvez ajouter (?) à la fin, c’est-à-dire qu’il y a un point d’interrogation après 1 $

réécrire ^/linux/(.*)$ /linux.php?distro=$1? last;

Dans l’exemple ci-dessus, la chaîne de remplacement inclut les arguments de la demande entrante, puis les arguments de la demande précédente ne se sont pas ajoutés après eux.

3.3.5. ‘’if’’ Le contexte et la directive de réécriture

Les quelques exemples suivants illustrent que nous pouvons utiliser la réécriture à l’intérieur de la directive ‘’if’’.

Vous pouvez effectuer une réécriture conditionnelle basée sur une comparaison de conditions ‘’if’’ à l’aide de variables telles que $scheme, $http_host, $http_user_agent, etc., comme indiqué ci-dessous :

si ($schéma = « http ») {

  réécrire ^ https://www.thegeekstuff.com$uri permanent ;

}

if ($http_host = thegeekstuff.com) {

  réécrire (.*) https://www.thegeekstuff.com$1 ;

}

if ($http_user_agent = MSIE) {

    réécrire ^(.*)$ /pdf/$1 pause ;

}

Notez aussi qu’il existe de meilleures façons d’atteindre le résultat final des exemples ci-dessus. 

Les exemples ci-dessus sont juste donnés pour montrer que nous pouvons ajouter une directive de réécriture à l’intérieur de l’instruction ‘’if’’ dans le fichier de configuration nginx.

Veuillez noter que vous pouvez également définir la valeur des deux paramètres suivants sur on ou off dans votre fichier de configuration nginx :

nom_serveur_en_redirection sur

port_in_redirect désactivé

3.3.6. Capturer les hits de réécriture Nginx dans le fichier journal des erreurs

Par défaut, chaque fois que Nginx effectue une réécriture réussie, il ne l’enregistre pas dans le fichier error.log.

Au départ, lorsque vous écrivez des règles de réécriture complexes, vous devez vraiment vous assurer que Nginx effectue la réécriture selon vos besoins.

Pour cela, vous devez activer le journal de réécriture, qui écrira une entrée de journal chaque fois que nginx effectuera une réécriture réussie en utilisant l’une des directives de réécriture du fichier de configuration.

Pour cela,

• Utilisez la directive rewrite_log et réglez-la sur on ;
• Ajoutez les deux lignes suivantes à votre nginx default.conf :

avis error_log /var/log/nginx/error.log ;

rewrite_log sur ;

La première ligne indique l’emplacement du fichier error_log où l’on doit écrire les messages de réécriture. 

Veuillez noter qu’un message de réécriture est de type notice. Donc, vous devez ajouter ‘’note’’ à la fin de cette ligne comme indiqué ci-dessus.

3.4. Quel est le vrai problème des règles de réécriture d’URL ?

Les développeurs d’applications Web utilisent les règles de réécriture d’URL pour masquer les paramètres dans la structure du chemin d’URL. 

Cela permet aux moteurs de recherche d’indexer plus facilement toutes les pages d’un site Web, tandis que les navigateurs web reçoivent l’URL dans un format qu’ils comprennent et qu’il est facile pour les utilisateurs de s’en souvenir.

Il est important de s’assurer que ces demandes sont acceptées par l’application Web et que tous les paramètres des URL sont correctement analysés. 

Voici en résumé les problèmes qui peuvent survenir lorsque des logiciels d’analyse de vulnérabilité web automatisés tentent d’analyser des sites Web qui utilisent la technologie et les règles de réécriture d’URL :

3.4.1. Les paramètres dans les URL ne sont pas analysés  

Un problème courant rencontré par les analyseurs de vulnérabilité web lors de l’analyse des applications web qui utilisent la technologie de réécriture d’URL est que les analyseurs sont incapables d’identifier les paramètres dans les URL. 

Les analyseurs supposent que les URL sont des répertoires plutôt que des noms ou des valeurs de paramètres, et les laissent non analysés.

3.4.2.  Analyses de vulnérabilité prolongées 

Ce problème peut entraîner des analyses prolongées et des résultats d’analyse incorrects. 

Par exemple, si le scanner de vulnérabilité web analyse une base de données d’outils qui contient 100 000 outils, puisque le scanner est incapable d’identifier qu’il y a un paramètre et une valeur dans l’URL, il penserait qu’il s’agit de pages différentes. Il va donc essayer de les explorer et de les scanner tous.

Si les problèmes de mémoire et autres exceptions ne sont pas gérés correctement par votre scanner, cela pourrait également entraîner le fait que votre logiciel commence par se planter et cela vous laisse sans résultats.

3.4.3. La configuration des règles de réécriture d’URL est un processus difficile : 

Étant donné que la technologie de réécriture d’URL est devenue très populaire dans les applications web, de nombreux scanners de vulnérabilité web commerciaux permettent aux utilisateurs de configurer le scanner.  Cela leur permet d’identifier les paramètres dans les URL et de les analyser.

Mais même si les scanners de vulnérabilité web peuvent être configurés pour analyser les sites web à l’aide des règles de réécriture d’URL, les utilisateurs peuvent rencontrer plusieurs autres problèmes comme :

• La configuration de la prise en charge des règles de réécriture d’URL est très difficile ;
• L’utilisateur doit savoir écrire des expressions régulières ;
• L’utilisateur doit avoir accès aux fichiers de configuration du serveur Web.

Alors, si vous n’êtes pas le développeur de l’application web elle-même ou si vous n’avez aucune connaissance approfondie de l’application web, il est impossible de configurer des règles de réécriture d’URL sur le scanner. 

Et, même si vous savez comment le faire, la configuration des règles de réécriture est une tâche très difficile et chronophage.

3.4.4. Les applications Web ne sont pas correctement scannées pour les vulnérabilités 

En supposant que vous parveniez à configurer des règles de réécriture d’URL dans votre scanner de vulnérabilité web, il existe d’autres problèmes.

Il existe un certain nombre de limitations à la façon dont les scanners analysent l’application web. Par mesure de sécurité, les applications web n’acceptent pas les requêtes HTTP déjà ‘’traduites’’. 

Par défaut, les applications Web .NET n’acceptent pas les requêtes HTTP. 

Le problème devient encore plus important lors de l’analyse des applications Web MVC, car ces applications utilisent une approche différente de la réécriture d’URL.

Une fois que vous avez configuré les règles de réécriture d’URL dans votre analyseur, celui-ci envoie un type de requêtes HTTP appelées requêtes traduites. 

Même si l’analyseur de sécurité des applications web signale que l’analyse s’est déroulée avec succès, la plupart des requêtes HTTP sont refusées et les paramètres des URL ne sont pas analysés, ce qui vous donne un faux sentiment de sécurité.

Conclusion

On note que la réécriture d’URL est parfois primordiale pour assurer que votre adresse ne donne pas un mauvais pressentiment aux internautes.

C’est un processus qui offre de nombreux avantages du point de vue SEO et crédibilité du site web.

Dans ce contenu, nous avons clarifié le concept de réécriture d’URL et nous avons accompagné cela des meilleures manières pour réécrire vos adresses URL.

Nous vous invitons à partager avec nous vos avis et d’autres ressources sur le concept de réécriture d’URL.