J'ai hérité de la prise en charge d'un site Opencart 1.5 sur lequel SSL doit être activé.
J'ai modifié les fichiers config.php
dans /
et admin/
et ajouter https://
à l'URL fonctionne dans le navigateur et des liens sont générés avec HTTPS.
Cependant, quelle que soit la méthode de redirection .htaccess
que j’essaie, le site ne se charge pas.
Ce qui suit est dans le fichier .htaccess
et je soupçonne que le problème est lié à la dernière ligne ici avec route que je n’ai jamais vue auparavant. .
RewriteBase /
RewriteRule ^sitemap.xml$ index.php?route=feed/google_sitemap [L]
RewriteRule ^googlebase.xml$ index.php?route=feed/google_base [L]
RewriteRule ^download/(.*) /index.php?route=error/not_found [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css)
RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]
Des suggestions sur la façon dont je peux ajouter HTTPS à cette RewriteRule?
Informations ajoutées ...
J'ai essayé divers ajouts dans le fichier .htaccess
, par exemple
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_Host}/$1 [R=301,L,NE]
Si j'ajoute cela après la redirection existante, cela ne semble pas avoir d'effet.
Si je l’ajoute juste après le RewriteBase /
Firefox me donne le message:
La page ne redirige pas correctement
Dans le débogueur de Firefox, il est dit
à propos de: neterror? e = redirectLoop & u = https% 3A // www.example.com/& c = ....
L'onglet Réseau affiche 21 demandes avec un statut de 301
SSL est géré par la société d'hébergement mais sans la nouvelle redirection, ajouter s
à l'adresse génère un site SSL opérationnel.
Si j'ajoute cela après la redirection existante, cela ne semble pas avoir d'effet.
Oui c'est correct. Les directives mod_rewrite s'exécutent de haut en bas (dans n'importe quel contexte). Les directives existantes implémentent un modèle de type de contrôleur frontal et par conséquent réécrivent most requêtes à index.php
. Si la demande est réécrite, alors les directives qui suivent (c'est-à-dire votre redirection) ne sont tout simplement jamais traitées. (Cependant, changez votre demande en quelque chose comme /foo/bar.css
- que ce fichier existe ou non - et la redirection devrait quand même être déclenchée.)
Si je l'ajoute juste après que RewriteBase/Firefox me donne le message:
Oui, la redirection HTTP vers HTTPS devrait être placée en haut de votre fichier. Après la directive RewriteBase
est un endroit logique pour le mettre.
La page ne redirige pas correctement
En d'autres termes, vous voyez une boucle de redirection. Avec la directive que vous avez donnée, qui utilise le HTTPS
variable de serveur, cette erreur implique que votre hôte a implémenté SSL avec une sorte de proxy frontal et de trafic provenant du proxy frontal. sur votre site est probablement un HTTP ancien (c'est-à-dire non chiffré).
Vous devez préciser à votre hébergeur que c'est le cas et qu'il devrait pouvoir vous dire exactement quelle (s) directive (s) vous devriez utiliser. Cela peut être spécifique à la configuration de votre serveur.
Certains hôtes définissent une variable HTTPS
environment (oui, même nom, mais variable différente) lorsque la demande arrive via HTTPS. Ceci est accessible comme %{ENV:HTTPS}
(par opposition à %{HTTPS}
). C'est assez courant, mais spécifique au serveur.
Un serveur proxy standard définira l'en-tête de requête HTTP X-Forwarded-Proto
dans la requête transférée à votre serveur d'applications. Vous pouvez donc effectuer la redirection HTTP vers HTTPS requise avec à la place ce qui suit:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://www.example.com/$1 [R=301,L,NE]
Cependant, vous devez préciser à votre hébergeur que c’est bien ainsi que le protocole SSL est mis en œuvre avant d’utiliser ce genre de chose en production. Sinon, si votre site ne se trouve pas derrière un serveur proxy (SSL), il est alors possible que quelqu'un construise une requête illicite et empêche le site de rediriger vers le site HTTPS.
Étant donné que vous manipulez des redirections 301 (permanentes), vous devez vider le cache de votre navigateur avant de tester.
De côté: quelques commentaires supplémentaires sur le code .htaccess
suivant ...
RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css) RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]
J'ai souvent vu ce code se répéter avec OpenCart (en fait, il semble faire partie de la distribution officielle ), mais il me semble un peu étrange/déroutant:
La présence de la directive 3rd RewriteCond
vérifiant REQUEST_URI
empêche toute requête contenant .ico
ou .gif
etc. (c'est-à-dire, généralement, "ressources statiques"), Opencart. Cependant, puisque cette vérification apparaît après les deux premières conditions qui vérifient déjà les fichiers/répertoires existants, il s’agit d’une vérification des demandes adressées à des "ressources statiques" qui ne mappent pas réellement sur de vrais fichiers?! Est-ce une fonctionnalité de sécurité?
Une vérification de cette nature est généralement mise en œuvre pour améliorer l'efficacité car les vérifications du système de fichiers sont "coûteuses". Mais pour faire cela, il devrait être implémenté comme une règle séparée avant le contrôleur frontal. Cela aurait le même avantage de "sécurité" (?) Que ci-dessus, mais avec une efficacité améliorée.
En d’autres termes, supprimez cette directive RewriteCond
et utilisez le système suivant before à la place du contrôleur frontal (bien que la regex demande toujours une ancre de fin de chaîne, c.-à-d. $
à la fin de la regex, sinon il correspond .css
(par exemple) n'importe où dans l'URL - peut-être que c'est l'intention, mais c'est aussi moins efficace):
RewriteRule \.(ico|gif|jpg|jpeg|png|js|css) - [L]
La RewriteRule
modèle^([^?]*)
ressemble à une erreur de débutant. À première vue, il se peut que look semble essayer de capturer tout ce qui se trouve dans l'URL, sans inclure la chaîne de requête (qui commence par un littéral ?
dans l'URL). Cependant, la chaîne de requête ne fait pas partie du chemin URL auquel correspond RewriteRule
modèle. Au lieu de cela, cela correspond à tout jusqu'au premier RL-codé?
dans le chemin d'URL (le cas échéant). C'est étrange, à moins que ce ne soit une autre fonctionnalité "de sécurité"? Mais s'il s'agit d'une fonctionnalité "de sécurité", elle devrait plutôt être implémentée en tant que directive de blocage plus tôt dans le fichier .htaccess
?
Malheureusement, je n'ai pas pu trouver d'explication supplémentaire sur la raison pour laquelle les directives auraient pu être écrites de cette façon.