web-dev-qa-db-ja.com

_route _ = $ 1でhtaccessファイルRewriteRuleに強制httpsを追加する方法

SSLを有効にする必要があるOpencart 1.5サイトのサポートを受け継ぎました。

config.phpおよび/のadmin/ファイルを編集し、URLにhttps://を追加すると、ブラウザーで機能し、HTTPSでリンクが生成されます。

ただし、.htaccessリダイレクトのどの方法を試しても、サイトがロードされないようです。

以下は.htaccessファイルにあり、問題はここで最後の行に関連していると思われますroute 。

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]

このRewriteRuleにHTTPSを追加する方法に関する提案はありますか？

情報を追加...

.htaccessファイルにさまざまな追加を試しました。たとえば

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

既存のリダイレクトの後に追加すると、効果がないように見えます。

RewriteBase /の直後に追加すると、Firefoxから次のメッセージが表示されます。

ページが正しくリダイレ​​クトされていません

Firefoxデバッガーでは

about：neterror？e = redirectLoop＆u = https％3A // www.example.com /＆c = ....

[ネットワーク]タブには、ステータスが301の21のリクエストが表示されます

SSLはホスティング会社によって管理されていますが、新しいリダイレクトを試みずにsをアドレスに追加すると、SSLサイトが機能します。

htaccessapachehttpsmod-rewriteopencart
4
Andrew Real

既存のリダイレクトの後に追加すると、効果がないように見えます。

はい、それは正しいです。 mod_rewriteディレクティブは、（特定のコンテキストで）トップダウンで実行します。既存のディレクティブは、フロントコントローラータイプパターンを実装し、その結果、most要求をindex.phpに書き換えます。リクエストが書き換えられた場合、後続のディレクティブ（リダイレクトなど）は処理されません。 （ただし、このファイルが存在するかどうかに関係なく、リクエストを/foo/bar.cssのようなものに変更すると、リダイレクトが引き続きトリガーされるはずです。）

RewriteBase/Firefoxからメッセージが表示された直後に追加した場合：

はい、HTTPからHTTPSへのリダイレクトをファイルの先頭に配置する必要があります。 RewriteBaseディレクティブの後は、それを置く論理的な場所です。

ページが正しくリダイレ​​クトされていません

つまり、リダイレクトループが発生しています。 HTTPSserver variableを使用する指定したディレクティブを使用すると、このエラーは、ホストが何らかのフロントエンドプロキシとからのトラフィックでSSLを実装していることを意味します。サイトへのフロントエンドプロキシは、おそらく昔ながらのHTTP（つまり、暗号化されていない）です。

これが事実であり、使用するディレクティブを正確に伝えることができることをウェブホストに明確にする必要があります。これは、サーバー構成に固有の場合があります。

一部のホストは、リクエストがHTTPS経由で受信されるときに、HTTPSenvironment変数（はい、同じ名前ですが、異なる変数）を設定します。これは、%{ENV:HTTPS}（%{HTTPS}とは対照的に）のようにアクセスされます。これはかなり一般的ですが、サーバー固有です。

標準プロキシサーバーは、アプリケーションサーバーへの転送されたリクエストにX-Forwarded-Proto HTTPリクエストヘッダーを設定します。そのため、代わりに次のような方法で必要なHTTPからHTTPSへのリダイレクトを実行できます。

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://www.example.com/$1 [R=301,L,NE]

ただし、本番環境でこのようなものを使用する前に、これが実際にSSLの実装方法であることをWebホストに明確にする必要があります。それ以外の場合、サイトが（SSL）プロキシサーバーの背後にない場合、誰かが悪意のあるリクエストを作成し、サイトがHTTPSにリダイレクトされないようにすることができます。

301（永続）リダイレクトを使用しているので、テストする前にブラウザのキャッシュをクリアする必要があります。

さておき：次の.htaccessコードに関するいくつかの追加コメント...

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]

OpenCartに関してこのコードが何度も繰り返されているのを見てきました（実際には 公式配布 の一部のようです）が、少し奇妙で不可解なように感じます。

  1. REQUEST_URIに対してチェックする3番目のRewriteCondディレクティブの存在は、.icoまたは.gifなど（つまり、通常「静的リソース」）を含む要求がルーティングされないようにします。 Opencart。ただし、このチェックは、既存のファイル/ディレクトリをすでにチェックしている最初の2つの条件の後に表示されるため、実際のファイルに実際にマッピングされない「静的リソース」へのリクエストのチェックになります。これはセキュリティ機能ですか？

    ファイルシステムのチェックは「高価」であるため、この性質のチェックは通常、効率を改善するために実装されます。しかし、それを行うには、フロントコントローラーの前に別のルールとして実装する必要があります。これにより、上記と同じ「セキュリティ」（？）メリットが得られますが、効率が向上します。

    言い換えると、このRewriteCondディレクティブを削除し、代わりにフロントコントローラーの次のようなbeforeのようなものを使用します（正規表現はまだ文字列の終わりを求めています）アンカー、つまり正規表現の末尾にある$、そうでない場合は.css（たとえば）URLのどこにでも一致します-おそらくそれが意図ではありますが、効率も劣ります）：

    RewriteRule \.(ico|gif|jpg|jpeg|png|js|css) - [L]

  2. RewriteRulepattern^([^?]*)は初心者の間違いのように見える。一見すると、lookクエリ文字列（リテラル?で始まるURLのすべてをキャプチャしようとしているように見えるかもしれません） URL）。ただし、クエリ文字列はRewriteRulepatternに一致するURLパスの一部ではありません。代わりに、これはURLパスの最初のURL-encoded?（存在する場合）までのすべてに一致します。別の「セキュリティ」機能でない限り、これは奇妙なことですか？しかし、それが「セキュリティ」機能である場合、代わりに.htaccessファイルの前のブロックディレクティブとして実装する必要がありますか？

残念ながら、ディレクティブがこのように書かれた理由について、これ以上の説明を見つけることができませんでした。

1
MrWhite