web-dev-qa-db-ja.com

httpsドメインからhttpドメインにリファラーヘッダーを渡すにはどうすればよいですか？

私のウェブサイトは100％httpsです。他のhttpドメインへのリンクがあります。 httpsページからhttpページにリンクする場合、リファラーヘッダーは設定されません。から http://en.wikipedia.org/wiki/HTTP_referrer

WebサイトがHTTPセキュア（HTTPS）接続からアクセスされ、リンクが別の安全な場所以外の場所を指している場合、リファラーフィールドは送信されません。

他のドメインcanがリファラーを参照して、トラフィックが私のドメインから来ていることを知ることを希望します。このヘッダーを強制する方法はありますか、または別の解決策がありますか？

更新

リダイレクトを使用していくつかの基本的なテストを行いました。

http page  -- link to http  --> 301 redirect --> http page = referrer intact
https page -- link to https --> 301 redirect --> http page = referrer blank
https page -- link to http  --> 301 redirect --> http page = referrer blank
https page -- link to http  --> 302 redirect --> http page = referrer blank

Httpsページから自分のドメインのhttpリダイレクトページにリンクすると、リファラーが失われます。そのため、リダイレクトにはリファラーはありません。

analyticshttpslinksreferrer
11
nutcracker

HTTPSページから別のドメインのHTTPページへのリンクを設定し、次の手法を使用してリファラーとして最初のページのURLを渡すことができました。

定義

元のページ：HTTPホスト先ページへのリンクがあるHTTPSページ。この例では：https://example1.com/Origin.html

宛先ページ：OriginページのリファラーにアクセスできるHTTPページ。この例では：http://example2.com/destination.html

基本計画

これには、リダイレクトをOriginページのHTTPバージョンから作成する効果があります。

  1. HTTPS Originページのリンクは現在のページにリンクしますが、リンク先ページのクエリパラメーターを追加します[1]。例：https://example1.com/Origin.html?goto=http://example2.com/destination.html

  2. リンクがクリックされると、example1.comのサーバーは、クエリパラメーター「goto」が存在する場合に標準リクエストを中断します。それから：

    • 「goto」パラメータを「goto」Cookieに保存します。
    • 現在のリクエストのURLから「goto」パラメータと値を削除します
    • 302は、OriginドメインのHTTPバージョンのこの新しいクリーンなURLにリダイレクトします。 http://example1.com/Origin.html

  3. サーバーは、「goto」Cookieのすべてのリクエストをチェックし、存在する場合はCookieをクリアしてから、非常に単純なリダイレクトページを表示します。このページには次が含まれます[2]：

    • Goto cookie urlにリダイレクトするJavascript window.location.replace（）スクリプト。
    • Goto cookie urlの値と数秒の遅延を持つMeta Refreshタグ。
    • Goto cookie URLへのリンク。

ノート

[1]この基本的な解決策は オープンリダイレクタ であり、gotoクエリパラメータを使用してフィッシング攻撃でUAをリダイレクトする悪者からの保護を考慮する必要があります。

[2] JSリダイレクトまたはメタリフレッシュタグを介してリダイレクトする場合、すべてのブラウザーがリファラーを送信するわけではありません。私のテストでは、IE8以前はリファラーに合格しません。

この手法により、検索エンジンのクローラーがリンクをたどることができるかどうかはわかりません。これは私の要件にとって重要ではありません。

UAでCookieが無効になっている場合、これは再びOriginページにリダイレクトされます。

リダイレクトのみにHTTP接続を許可する

私のサーバーには、リクエストに関係なくHTTPSを強制するためのApacheルールがあります。

<VirtualHost *:80>
    ServerName example1.com

    # if not on port 443 then 301 redirect to https while keeping any query string
    RewriteEngine              On
    RewriteCond %{HTTP_Host}  ^example1\.com$ [NC]
    RewriteCond     %{SERVER_PORT} !443
    RewriteRule     ^(.*)$     https://%{HTTP_Host}$1 [L,QSA,R=301]

上記のリダイレクト手法を機能させるには、HTTP接続を条件付きで許可する何らかの方法が必要です。これを行うには多くの方法があります。 Cookieが機能すると判断しました。

<VirtualHost *:80>
    ServerName example1.com

    # if not on port 443 then 301 redirect to https while keeping any query string
    RewriteEngine              On
    RewriteCond %{HTTP_Host}  ^example1\.com$ [NC]
    RewriteCond     %{SERVER_PORT} !443
    RewriteCond %{HTTP_COOKIE}  !disable_ssl [NC]
    RewriteRule     ^(.*)$     https://%{HTTP_Host}$1 [L,QSA,R=301]

Disable_ssl Cookieは手順2で設定され、手順3で削除されます。

5
nutcracker

前述のとおり、 この回答 これを行う新しい方法があります：リファラーポリシー/メタタグ。

spec および このq＆aの例 を参照してください。

9
Abbafei

私もこれと同じ問題を抱えていました。以下のようなメタタグを追加することで解決し、ChromeおよびSafariでのみ動作します。

<meta name="Referrer" content="Origin">
8
Mahendran Sakkarai

残念ながら、HTTPSを使用してHTTPを使用するサイトを参照することはできません。ただし、HTTPSからHTTPSまたはHTTPからHTTPSを実行できます。

ソース

参照ページがセキュアなプロトコルで転送された場合、クライアントは（非セキュア）HTTPリクエストにRefererヘッダーフィールドを含めるべきではありません。

回避策は、HTTPにリダイレクトしてからリダイレクトするHTTPSで訪問者にリンクアウトするのではなく、内部リダイレクトスクリプトを使用することです。

例えば：

<a href="http://www.yours.com/out.php?www.other.com">www.outboundsite.com</a>が、これは元のリファラーを使用しません。

別の可能性は、リファラーではなく trackbacks を使用することであり、これがHTTPSで機能することを知っている限りです。

6
Simon Hayter

hTTP 1.1プロトコルに準拠 http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.

参照ページがセキュアで転送された場合、クライアントは、（非セキュア）HTTPリクエストにRefererヘッダーフィールドを含めるべきではありません（SHOULD NOT）

2
tony

あなたが望むものは不可能であるように見えるので、可能な回避策;ターゲットサイトがGoogleアナリティクスを使用している場合（またはPiwikが同様の構文を使用していると思われる互換性のあるプログラム、および他の統計パッケージはこれを無視する場合があります）、example.comへのリンクなどで追跡パラメーターを送信できます

http://www.example.com/?utm_campaign=spring&utm_medium=referral&utm_source=exampleblog

これは詳細とともにGAに表示されます。他の人が使用する可能性が低い値を選択して、競合を強制したり、他人の背後にトラフィックを隠したりしないでください。

Googleはここで便利なURLビルダーを行います http://support.google.com/analytics/answer/1033867?hl=ja

更新-re：エチケット

トラフィックの性質について詳しく知ることなく、私は一般的/個人的にしか話せません...

エチケットは常に見る人の目に入るでしょう。これがないと、GAに少なくとも直接表示されるか、または（セットなしで）数字が歪んでブランドが実際よりも大きく見えるように見える可能性があります。個人的には、トラフィックの発信元がわかるように、慎重に選択したキャンペーンを好むでしょう。

また、トラフィックをほとんど送信しなくても、おそらく気付かないでしょう。大量に送信しても、文句を言うことはないでしょう。もしそうなら、あなたは通常無料のトラフィックを与える他の誰かを見つけることができます！

そして、あなたが非常に具体的であれば、それは問題を引き起こすべきではありません。サイトの名前としてのキャンペーンと、サイトのセクションとしてのソースですか？

http://www.example.com/?utm_campaign=mygreatsite.com&utm_medium=referral&utm_source=specialoffers
0
CodeMonkey