web-dev-qa-db-fra.com

Wordpress htaccess redirige de http à https

Actuellement, j'utilise cette règle sur mon fichier WordPress .htaccess pour rediriger HTTP vers HTTPS:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_Host}%{REQUEST_URI} [L,R=301]
</IfModule>

Mais j'ai trouvé d'autres règles que celle que j'ai utilisée comme celle-ci:

RewriteEngine On
 RewriteCond %{HTTPS} !on
 RewriteCond %{SERVER_PORT} !^443$ 
RewriteCond %{HTTP:X-Forwarded-Proto} !https 
RewriteRule ^(.*)$ https://%{HTTP_Host}/$1 [R=301,L]

Je ne sais pas si ces 2 règles font le même travail ou s'il y en a une autre qui convient le mieux pour la redirection de HTTP à HTTPS

OU la règle que j'ai utilisée sur mon fichier .htaccess est assez parfaite pour effectuer la redirection de HTTP vers HTTPS?

htaccess301-redirecthttps
2
Webdev

Mélanger et assortir!

Ils sont tous les deux assez similaires sauf RewriteCond %{HTTP:X-Forwarded-Proto} !https

Ceci est un proxy inverse/équilibreur de charge qui n’est pas totalement compatible avec toutes les configurations, mais qui convient si vous en utilisez une.

Mieux vaut faire un mix si vous n’êtes pas sûr.

Comme ça:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https 
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_Host}%{REQUEST_URI} [L,R=301]
</IfModule>
2
Invariant Change

Comme avec beaucoup de systèmes de programmation flexibles , il existe souvent de nombreuses façons différentes de faire la même chose. Un moyen n'est pas nécessairement "meilleur" qu'un autre. Cependant, différentes méthodes peuvent être requises en fonction de besoins spécifiques ou de configurations de serveur différentes.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_Host}%{REQUEST_URI} [L,R=301]
</IfModule>

Il n'y a rien de mal à cela. Si cela fonctionne pour vous alors allez-y. Cependant, vous devriez être conscient de ce qu'il fait réellement. Plus précisément, il redirige vers la même URL sur le même hôte . En soi, cela ne canonise pas le sous-domaine www - vous pouvez donc voir deux redirections pour certaines demandes non canoniques (par exemple, si WordPress, ou une autre partie de votre configuration, canonise le sous-domaine www). Maintenant, ce n'est pas nécessairement une mauvaise chose - si vous implémentez HSTS alors c'est en fait une exigence. Toutefois, si vous n’implémentez pas le système HSTS, vous pouvez envisager d’incorporer votre redirection www canonique de manière à ne recevoir qu’une seule redirection.

Cependant, ces directives pourraient être un peu "rangées":

  • Vous n'avez pas besoin du wrapper <IfModule>, sauf si vous utilisez ces directives sur d'autres serveurs où mod_rewrite risque de ne pas être disponible et que vous disposez d'un code serveur "de sauvegarde" qui redirige HTTP vers HTTPS lorsque mod_rewrite n'est pas disponible. Sinon, ces directives sont considérées obligatoires et le wrapper <IfModule> devrait être supprimé.

  • Puisque vous utilisez WordPress, qui a déjà son propre bloc de directives mod_rewrite, vous n’avez absolument pas besoin de répéter la directive RewriteEngine On - même si ces directives sont (supposément) présentes avant les directives WP. (La directive last RewriteEngine du fichier .htaccess gagne et contrôle l'ensemble du fichier/contexte.)

  • Optimisation des expressions rationnelles: ^(.*)$ - vous n'avez pas besoin des parenthèses de capture dans le modèle RewriteRule lorsque vous n'utilisez pas la référence arrière dans la substitution (ou les conditions précédentes ). En d'autres termes, vous voulez changer ceci: ^.*$ (ou simplement .* puisque les ancres ne sont pas nécessaires non plus - l'expression régulière est gourmande par défaut).

En résumé:

RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_Host}%{REQUEST_URI} [L,R=301]

RewriteCond %{HTTPS} !on
RewriteCond %{SERVER_PORT} !^443$ 
RewriteCond %{HTTP:X-Forwarded-Proto} !https 
RewriteRule ^(.*)$ https://%{HTTP_Host}/$1 [R=301,L]

Oui, cela fait "le même travail", mais d'une manière différente. Comme le suggère @ Invariant dans sa réponse, la troisième condition qui vérifie l'en-tête de la requête HTTP X-Forwarded-Proto est requise lorsque derrière un serveur proxy (ou un équilibreur de charge) - bien que cela puisse varier (tous les proxys ne fonctionnent pas de la même manière).

Cependant, ces directives sont "excessives" et pas strictement correctes. Si vous êtes derrière un proxy, les deux premières conditions sont probablement redondantes, car elles sont toujours considérées comme étant vraies . (Mais vous n'auriez pas besoin des deux de ces conditions en aucune circonstance - elles feront essentiellement la même chose.) Et si vous n'êtes pas derrière un proxy alors la troisième condition (qui vérifie X-Forwarded-Proto) ne doit pas être utilisée car elle rendrait votre serveur vulnérable aux requêtes malveillantes qui injectent cet en-tête, incitant votre serveur à penser qu'il communique déjà via HTTPS alors qu'il ne le fait pas. .

La raison pour laquelle vous voyez des règles comme celle-ci (et le prétendu "avantage") est qu’elle est plus "générique" et est plus susceptible de fonctionner sur différentes configurations de serveur - elle peut être copiée/collée entre les sites et avoir une meilleure chance de " travail". Cependant, comme pour de nombreuses "solutions" génériques, elle introduit une redondance, est moins efficace et, dans ce cas, introduit potentiellement une vulnérabilité.

Lorsqu'elles sont utilisées dans .htaccess à la racine du document du site, les deux directives suivantes entraînent la même réponse.

RewriteRule .* https://%{HTTP_Host}%{REQUEST_URI} [L,R=301]

RewriteRule ^(.*)$ https://%{HTTP_Host}/$1 [R=301,L]

Toutefois, cette dernière ne fonctionnera pas si .htaccess se trouve ailleurs que la racine du document. Et cela ne fonctionnera pas "correctement" en dehors d'un contexte de répertoire (c'est-à-dire dans la configuration du serveur).

0
MrWhite