Comment rediriger toutes les requêtes HTTP vers HTTPS


294

J'essaie de rediriger toutes les requêtes HTTP non sécurisées de mon site (par exemple http://www.example.com) vers HTTPS ( https://www.example.com). J'utilise PHP btw. Puis-je le faire en .htaccess?


1
Vous pouvez (et devez) le faire via votre httpd, pas avec PHP.
Drudge

2
@jnpcl, bien que je convienne que la solution httpd est meilleure que la solution basée sur PHP, je ne pense pas qu'une redirection systématique soit une bonne pratique en général. Si vous souhaitez à tout moment rediriger vos utilisateurs vers HTTPS, envoyez-les depuis le "point d'entrée" (le premier lien vers votre site), ne le faites pas à mi-chemin, ce qui pourrait laisser fuir certaines données que vous pensez est protégé (si vous ne remarquez pas cette redirection instantanée).
Bruno

@Bruno: Je pensais davantage à des requêtes HTTP dupliquées, au potentiel de perte de chaînes de requête et à la possibilité pour l'utilisateur de taper manuellementhttp://
drudge

@jnpcl c'est un bon point en effet. Je suggérais simplement que, alors que les gens ont tendance à demander ce type de redirection pour améliorer la sécurité de leur site, cela ne l'améliore souvent pas (car cela n'empêche pas la même demande de passer par le HTTP standard en premier). .
Bruno

8
@outis: le premier lien que vous avez publié est cette question.
Mei

Réponses:


305

Mise à jour: Bien que cette réponse ait été acceptée il y a quelques années, notez que son approche est désormais déconseillée par la documentation Apache. Utilisez Redirectplutôt un . Voir cette réponse .


RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

24
@Cat, comme je le disais dans ma réponse / mes commentaires, si vous essayez de "rediriger tous les HTTP non sécurisés [...] vers HTTPS", cette approche ne sécurisera pas ces requêtes, elle fera simplement en sorte que le navigateur les fasse deux fois, une fois précaire et une fois sécurisé.
Bruno

13
Ce que vous devriez vraiment faire, c'est utiliser HSTS de concert avec cela.
Reese Moore

3
Cela peut être un bogue dans ma version d'apache (2.4.6 tel que conditionné dans Centos 7), mais cela me pose des problèmes sur certaines URL. Par exemple, les http://server/foo?email=someone%40example.comredirections vers, https://server/foo?email=someone%2540example.comc'est- à- dire que le signe "@" est cité deux fois par URL . L'utilisation de la méthode dans la réponse de @ ssc n'a pas ce problème.
psmears

2
Mauvaise réponse. Il ne redirigera que l'URL de base, pas les URL des sous-dossiers. RewriteRule (. *) Https: //% {HTTP_HOST}% {REQUEST_URI} [R = 301, L] est la bonne réponse
FredTheWebGuy

7
Ils ne le recommandent pas nécessairement:In the case of the http-to-https redirection, the use of RewriteRule would be appropriate if you don't have access to the main server configuration file, and are obliged to perform this task in a .htaccess file instead.
Adam

338

Les documents Apache déconseillent d'utiliser une réécriture:

Pour rediriger les httpURL vers https, procédez comme suit:

<VirtualHost *:80>
    ServerName www.example.com
    Redirect / https://www.example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName www.example.com
    # ... SSL configuration goes here
</VirtualHost>

Cet extrait devrait aller dans le fichier de configuration du serveur principal, pas dans .htaccesscomme demandé dans la question.

Cet article n'a peut-être été publié qu'après que la question a été posée et répondue, mais semble être la voie à suivre actuellement.


11
Ce devrait être la réponse actuelle. Mais que se passe-t-il exactement dans la "configuration SSL"? Un exemple complet serait vraiment utile.
Ben

6
@Ben: c'est une question différente qui est largement documentée en ligne; Soit dit en passant , je viens d'ajouter un exemple presque complet hier: serverfault.com/q/597012/26210 qui pourrait vous donner une idée de ce qui se passe dans la configuration SSL
ssc

46
Ceci est un excellent indice. Mais le document Apache mentionne également: "Dans le cas de la redirection http vers https, l'utilisation de RewriteRule serait appropriée si vous n'avez pas accès au fichier de configuration du serveur principal et êtes obligé d'effectuer cette tâche dans un fichier .htaccess à la place. " C'est le cas pour moi ...
peter_the_oak

4
@ user1844933 Si vous utilisez le permanentmot - clé, l'effet est le même (le navigateur reçoit une redirection 301). Par exemple:Redirect permanent "/" "https://example.com"
BeetleJuice

2
@Whitecat Dans Centos 6, le fichier se trouve dans /etc/httpd/conf/httpd.conf
dstonek

141

Je recommanderais avec la redirection 301:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

7
merci, cela fonctionne pour moi, la réponse acceptée ne le fait pas .. probablement en raison du manque de[L]
billynoah

1
Oui. C'est la bonne réponse car elle achemine également toutes les URL dans les sous-dossiers
FredTheWebGuy

Est-ce au niveau supérieur du fichier htaccess?
CodyBugstein

1
@CodyBugstein C'est là que je le place toujours, et ça marche toujours.
Daan van den Bergh

3
Toutes les réponses manquent d'une chose - tout code de redirection doit être placé juste au début de votre fichier .htaccess, AVANT toute autre chose, si vous voulez que toutes les pages soient redirigées vers https.
Vadim Anisimov

35

Comme je le disais dans cette question , je vous suggère d'éviter de rediriger toutes les requêtes HTTP vers leur équivalent HTTPS à l'aveugle, car cela pourrait vous donner une fausse impression de sécurité. Au lieu de cela, vous devriez probablement rediriger la «racine» de votre site HTTP vers la racine de votre site HTTPS et créer un lien à partir de là, uniquement vers HTTPS.

Le problème est que si un lien ou un formulaire sur le site HTTPS oblige le client à envoyer une demande au site HTTP, son contenu sera visible avant la redirection.

Par exemple, si l'une de vos pages servies via HTTPS a un formulaire qui dit <form action="http://example.com/doSomething">et envoie des données qui ne devraient pas être envoyées en clair, le navigateur enverra d'abord la demande complète (y compris l'entité, s'il s'agit d'un POST) au site HTTP première. La redirection sera envoyée immédiatement au navigateur et, comme un grand nombre d'utilisateurs désactivent ou ignorent les avertissements, il est probable qu'elle soit ignorée.

Bien sûr, l'erreur de fournir les liens qui devraient être vers le site HTTPS mais qui finissent par être pour le site HTTP peut causer des problèmes dès que vous obtenez quelque chose à l'écoute sur le port HTTP sur la même adresse IP que votre site HTTPS. Cependant, je pense que garder les deux sites en tant que "miroir" augmente seulement les chances de faire des erreurs, car vous pouvez avoir tendance à supposer qu'il se corrigera automatiquement en redirigeant l'utilisateur vers HTTPS, alors qu'il est souvent trop tard. (Il y a eu des discussions similaires sur cette question. )


1
Lorsque vous décidez de servir un site entier en HTTPS, ce type de redirection est logique. Je ne veux pas qu'un utilisateur obtienne un 403 car il a spécifié http pour sa page de destination. Je suis d'accord si quelqu'un spécifie http dans un lien et le déploie vers une production qui EST mauvaise. Il DEVRAIT être intercepté pendant les tests, même avec la redirection en place. Je n'aime pas l'argument "pourrait" parce que ce "pourrait" se produire sans la redirection en place. Les symptômes sont les mêmes lors des tests dans un navigateur sécurisé, sauf après avoir confirmé l'envoi en clair qu'il redirige au lieu de recevoir un 403.
Derek Litz

Oui, je vois l'avantage d'échouer dur si quelqu'un met par erreur http dans une action de formulaire, mais être indulgent avec les URL saisies semble plus important dans la plupart des cas.
Daniel Lubarov

4
@Daniel, je suis d'accord qu'il est utile d'être indulgent lorsque les utilisateurs tapent l'URL. Je dirais que c'est l'un des cas où il vaut mieux désactiver cette fonctionnalité pendant le développement / test, mais l'activer en production (ou dans les dernières étapes du développement / test).
Bruno

pourquoi ne pas faire http à https sur dns.
Muhammad Umer

1
@MuhammadUmer, car cela n'a rien à voir avec le DNS. Ils utiliseraient le même nom d'hôte en général, mais même avec un nom d'hôte différent, vous devrez toujours modifier le protocole et le port.
Bruno

18

J'ai découvert que le meilleur moyen pour https et www sur le domaine est

RewriteCond %{HTTPS} off 
RewriteCond %{HTTPS_HOST} !^www.example.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

Cela ne redirigera pas http://www.example.com/...car les deux conditions sont implicitement ET. Ils devraient plutôt être opérés, c'est-à-dire. inclure le ORdrapeau sur la première condition (et n'oubliez pas d'échapper aux points littéraux dans l'expression régulière). Mais si vous implémentez HSTS alors vous ne voulez pas rediriger vers HTTPS et www dans une redirection unique, vous devez rediriger vers HTTPS premier .
MrWhite

Où dois-je mettre ce texte?
Aaron Franke

Sur le même type de question. Quelqu'un peut-il aider avec la question ci-dessous? stackoverflow.com/questions/59503217/…
appsntech

14

C'est l'approche de redirection html qui fonctionne, mais pas la meilleure.

 <meta http-equiv="Refresh" content="0;URL=https://www.example.com" />

Approche PHP

<?php
function redirectTohttps() {
    if ($_SERVER['HTTPS']!="on") {
        $redirect= "https://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
        header("Location:$redirect"); 
    } 
}
?>

Approche .htaccess

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

copié depuis: www.letuslook.org


Où va .htaccess-t-il? De plus, ce lien est mort.
Aaron Franke

8

J'aime cette méthode de redirection de http vers https. Parce que je n'ai pas besoin de le modifier pour chaque site.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

Où dois-je mettre ce texte?
Aaron Franke

6

L'utilisation du code suivant dans votre fichier .htaccess redirige automatiquement les visiteurs vers la version HTTPS de votre site:

RewriteEngine On

RewriteCond %{HTTPS} off

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

Si vous avez un fichier .htaccess existant:

Ne dupliquez pas RewriteEngine On.

Assurez-vous que les lignes commençant RewriteCond et RewriteRule suivent immédiatement le RewriteEngine On déjà existant.


Que signifient L et R?
Aaron Franke

5

C'est la bonne méthode pour rediriger HTTP vers HTTPS en utilisant .htaccess selon GoDaddy.com. La première ligne de code est explicite. La deuxième ligne de code vérifie si HTTPS est désactivé, et si c'est le cas, il redirige HTTP vers HTTPS en exécutant la troisième ligne de code, sinon la troisième ligne de code est ignorée.

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

https://www.godaddy.com/help/redirect-http-to-https-automatically-8828


5

La meilleure solution dépend de vos besoins. Ceci est un résumé des réponses précédemment publiées avec un peu de contexte ajouté.

Si vous travaillez avec le serveur Web Apache et pouvez modifier sa configuration, suivez la documentation Apache :

<VirtualHost *:80>
    ServerName www.example.com
    Redirect "/" "https://www.example.com/"
</VirtualHost>

<VirtualHost *:443>
    ServerName www.example.com
    # ... SSL configuration goes here
</VirtualHost>

Mais vous avez également demandé si vous pouviez le faire dans un .htaccessfichier. Dans ce cas, vous pouvez utiliser le RewriteEngine d'Apache :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L]

Si tout fonctionne correctement et que vous souhaitez que les navigateurs se souviennent de cette redirection, vous pouvez la déclarer permanente en remplaçant la dernière ligne par:

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

Mais soyez prudent si vous pouvez changer d'avis sur cette redirection. Les navigateurs s'en souviennent très longtemps et ne vérifieront pas s'il a changé.

Il se peut que vous n'ayez pas besoin de la première ligne en RewriteEngine Onfonction de la configuration du serveur Web.

Si vous recherchez une solution PHP, regardez le tableau $ _SERVER et la fonction d'en-tête :

if (!$_SERVER['HTTPS']) {
    header("Location: https://" . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']); 
} 

Il semble que la documentation Apache déconseille la route de réécriture. Et avec Redirect? Que peut-on faire d'autre dans un .htaccessfichier?
Aaron Franke

Oui, la redirection est préférée et peut être utilisée dans .htaccess. Mais vous ne pouvez pas ajouter la condition pour rediriger uniquement le trafic http vers https. Il redirige également https -> boucle de redirection infinie. Je l'ai répertorié dans la directive VirtualHost utilisée pour http (port 80) ci-dessus, .htaccess ne prend pas en charge cette directive et par conséquent, Redirect ne peut pas être utilisé ici.
maikel

4

Ajoutez le code suivant au fichier .htaccess:

Options +SymLinksIfOwnerMatch
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^ https://[your domain name]%{REQUEST_URI} [R,L]

Où [votre nom de domaine] est le nom de domaine de votre site Web.

Vous pouvez également rediriger des dossiers spécifiques hors de votre nom de domaine en remplaçant la dernière ligne du code ci-dessus par:

RewriteRule ^ https://[your domain name]/[directory name]%{REQUEST_URI} [R,L]

Que signifient L et R?
Aaron Franke

4

Faites tout ce qui est expliqué ci-dessus pour la redirection. Ajoutez simplement "HTTP Strict Transport Security" à votre en-tête. Cela évitera l'homme au milieu de l'attaque.

Modifiez votre fichier de configuration apache (/etc/apache2/sites-enabled/website.conf et /etc/apache2/httpd.conf par exemple) et ajoutez ce qui suit à votre VirtualHost:

# Optionally load the headers module:
LoadModule headers_module modules/mod_headers.so

<VirtualHost 67.89.123.45:443>
    Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
</VirtualHost>

https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security


2

Pour rediriger toutes les httpdemandes vers https, vous pouvez utiliser:

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [NE,L,R]

Si la réécriture mod n'est pas activée et que vous êtes sur apache 2.4, vous pouvez également utiliser une directive Redirectinside ifpour rediriger les httprequêtes vers https.

Apache 2.4.

<if "%{HTTPS} !~ /on/">
Redirect / https://www.example.com/
</if>

2

Si vous êtes dans une situation où vous ne pouvez pas accéder directement à la configuration d'apache pour votre site, dont de nombreuses plates-formes hébergées sont toujours restreintes de cette manière, alors je recommanderais en fait une approche en deux étapes. La raison pour laquelle Apache eux-mêmes documentent que vous devez utiliser leurs options de configuration d'abord et avant tout sur le mod_rewrite pour HTTP en HTTPS.

Tout d'abord, comme mentionné ci-dessus, vous devez configurer votre ou vos règles .htaccess mod_rewrite:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Ensuite, dans votre (vos) fichier (s) PHP (vous devez le faire là où cela convient à votre situation, certains sites achemineront toutes les demandes via un seul fichier PHP, d'autres serviront différentes pages en fonction de leurs besoins et de la demande en cours) ):

<?php if ($_SERVER['HTTPS'] != 'on') { exit(1); } ?>

Ce qui précède doit être exécuté AVANT tout code susceptible d'exposer des données sécurisées dans un environnement non sécurisé. Ainsi, votre site utilise une redirection automatique via HTACCESS et mod_rewrite, tandis que vos scripts garantissent qu'aucune sortie n'est fournie lorsqu'ils ne sont pas accessibles via HTTPS.

Je suppose que la plupart des gens ne pensent pas comme ça, et donc Apache recommande que vous n'utilisiez pas cette méthode si possible. Cependant, il suffit d'un contrôle supplémentaire à la fin du développement pour garantir la sécurité des données de votre utilisateur. J'espère que cela aidera quelqu'un d'autre qui pourrait avoir à chercher à utiliser des méthodes non recommandées en raison des restrictions sur nos services d'hébergement.


1

Grâce à .htaccess Cela vous aidera.

RewriteEngine On


RewriteBase /
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]

RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Référez-vous également à ceci pour plus de détails. Comment rediriger Http vers Https?


1
Il s'agit de la solution idéale pour quiconque obtient une "erreur de redirection trop importante" et ne peut pas modifier la propriété allowOverride.
Evochrome

1

Sauf si vous avez besoin de mod_rewrite pour d'autres choses, l'utilisation de la directive IF Apache core est plus propre et plus rapide:

<If "%{HTTPS} == 'off'">
Redirect permanent / https://yoursite.com/
</If>

Vous pouvez ajouter plus de conditions à la directive IF, telles que garantir un seul domaine canonique sans le préfixe www:

<If "req('Host') != 'myonetruesite.com' || %{HTTPS} == 'off'">
Redirect permanent / https://myonetruesite.com/
</If>

Il y a beaucoup d'inertie de familiarité dans l'utilisation de mod_rewrite pour tout, mais voyez si cela fonctionne pour vous.

Plus d'informations: https://httpd.apache.org/docs/2.4/mod/core.html#if

Pour le voir en action (essayez sans www. Ou https: //, ou avec .net au lieu de .com): https://nohodental.com/ (un site sur lequel je travaille).



0

J'ai trouvé une méthode pour forcer toutes les pages de mon site à rediriger de http vers des pages analogiques sur https qui fonctionnent pour moi.

RewriteEngine On 
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

0
 Redirect 301 / https://example.com/

(a fonctionné pour moi lorsqu'aucune des réponses ci-dessus n'a fonctionné)

Prime:

ServerAlias www.example.com example.com

(https fixe: // www .exemple.com introuvable)


0

Cela redirige toutes les URL vers https et www

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTPS_HOST} !^www.example.com$ [NC,OR]
RewriteCond %{HTTP_HOST} !^www.example.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

0

Si vous souhaitez le faire à partir du serveur tomcat, suivez les étapes ci-dessous

Dans un serveur HTTP Apache Tomcat (8.5.x) autonome, comment le configurer, donc si un utilisateur tape www.domain.com, il sera automatiquement transféré vers le site https (www.domain.com).

La méthode en 2 étapes pour inclure les éléments suivants dans votre [Tomcat_base] /conf/web.xml avant la balise de fermeture

step 1: 
<security-constraint>
<web-resource-collection>
<web-resource-name>HTTPSOnly</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

et définir les paramètres du connecteur [Tomcat_base] /conf/server.xml:

step 2:
<Connector URIEncoding="utf-8" connectionTimeout="20000" port="80" protocol="HTTP/1.1" redirectPort="443"/>
<Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol"
maxThreads="150" SSLEnabled="true">
<SSLHostConfig>
<Certificate certificateKeystoreFile="[keystorelocation]" type="RSA" />
</SSLHostConfig>
</Connector>

Remarque: Si vous avez déjà effectué la configuration https et que vous essayez de rediriger, effectuez l'étape 1 uniquement.



-1

Un avantage différent de ce problème est lorsqu'un équilibreur de charge entre en jeu.

La situation est la suivante: - Le trafic du navigateur vers Load Balancer, et inversement, est (devrait être) HTTPS - Le trafic entre Load Balancer et le WebServer réel est HTTP.

Ainsi, toutes les variables de demande de serveur en PHP ou Apache montrent que la connexion est juste HTTP. Et les répertoires HTTP et HTTPS sur le serveur sont les mêmes.

La condition de réécriture dans la réponse approuvée ne fonctionne pas. Cela donne soit une boucle, soit cela ne fonctionne tout simplement pas.

La question est: comment faire fonctionner ceci sur un équilibreur de charge.

(Ou le Load Balancer est-il mal configuré. C'est ce que j'espère car je pourrai ensuite transférer le problème à la société WebHosting :-))


La redirection devrait simplement se produire à la place sur l'équilibreur de charge. Selon le type d'équilibreur de charge, cela devrait être possible dans la configuration, ou c'est une instance apache elle-même, où la réponse acceptée fonctionnerait. Ne le faites pas sur les nœuds uniques.
marc82ch

-1

Si vous utilisez un équilibreur de charge élastique Amazon Web Services qui accepte le trafic https et le route vers vos serveurs avec http, la bonne façon de rediriger tout le trafic http vers https est décrite ici: https://aws.amazon. com / premiumsupport / centre de connaissances / redirect-http-https-elb

Utilisez l'en-tête X-Forwarded-Proto (contient http ou https) qui est toujours inclus dans les requêtes http de l'équilibreur de charge, comme décrit ici: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x- forwarded-headers.html

Dans le fichier httpd.conf:

<VirtualHost *:80>

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule .* https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent]

</VirtualHost>

Ou dans votre fichier racine .htaccess:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule .* https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent]

Bonus: il n'essaiera pas de rediriger le trafic http sur votre machine de développement locale.


-1

Ça marche pour moi:

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

et par exemple, http: // server / foo? email = quelqu'un% 40example.com redirige normalement sans aucun problème. Le fichier .htaccess situé dans le dossier racine du site Web (par exemple nommé public_html). Il est possible d'utiliser RewriteCond% {SERVER_PORT}! ^ 443 $ à la place RewriteCond% {HTTPS}! Sur

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.