none
リファラーチェックについて RRS feed

  • 質問

  • e-BOOKアプリケーション(http://www.page-view.jp/)を利用する際に、htaccessにて特定のURLからしかアクセスできないようにリファラーチェック(SetEnvIf Referer "^https://◯◯◯.◯◯" ref_ok)を設定して運用していたのですが、

    今年に入って一部機能(ヘルプやPDF表示など)がForbiddenになってしまいました。

    リリース時の2014年12月のタイミングでは問題ございませんでした。

    何か解決策などございましたらどなたかご意見いただけますでしょうか。

    2016年12月28日 6:42

回答

  • 佐祐理さんもコメントされていますが、この質問内容はこのフォーラム、カテゴリとどう関係するのでしょう?

    Forbidden しているのは http://www.page-view.jp/ のサービスの側なので、まずそのサービス側でどうして Forbidden にしているのか(リファラの問題なのか、それ以外に原因があるのか)を調査し、クライアントから送信されているリファラが期待通りでないためにそうなっているという事であれば、ここでの質問の題材となるでしょうがその点が明確でない以上、今の時点でここで質問するのはあまり適切でないように思えます。

    現時点でアドバイスできるとすれば、F12 開発者ツールの「ネットワーク」や Fiddler、ネットワーク パケット キャプチャなどでクライアントから実際にどのようなリファラが送信されているのか調査すると良さそう、という位でしょう。


    hebikuzure

    2016年12月28日 10:44
    モデレータ
  • Microsoft コミュニティ「リファラーチェックについて」からの移動のようで、そちらで IE がリファラとして URL のフラグメント部分(# 以降)も送信しているためではないかと書かれていますが、それを本件での実際の挙動として確認されたのでしょうか。

    リファラにはフラグメントを送信しないのが HTTP の RFC(https://tools.ietf.org/html/rfc7231#section-5.5.2)ですので、IE が実際にそういう挙動をするのであれば、

    で報告されている問題である可能性が考えられます。ただこの bug 報告は not repro で close されているので、他に再現条件があるのかもしれません。修正などについての情報が必要であれば、企業向け有償サポートを利用して問い合わせされると良いでしょう。

     


    hebikuzure

    2016年12月29日 7:40
    モデレータ
  • > リファラーチェック設定が影響しているだろうとのことです。実際設定を外すといずれのコンテンツの正常に機能します

    これが正しければ、次に行うべきは実際にどのようなリファラが送信されると撥ねられてしまうのか、先に書いたようにF12 開発者ツールの「ネットワーク」や Fiddler、ネットワーク パケット キャプチャなどで調査していくことでしょう。

    そこが明確になれば、アプリ側の改修要求などもしやすいと思います。


    hebikuzure

    2017年1月5日 6:32
    モデレータ

すべての返信

  • フォーラムのご利用方法(質問の投稿)についてを参照したうえで、投稿内容を読み返すことをお勧めします。
    2016年12月28日 9:32
  • 佐祐理さんもコメントされていますが、この質問内容はこのフォーラム、カテゴリとどう関係するのでしょう?

    Forbidden しているのは http://www.page-view.jp/ のサービスの側なので、まずそのサービス側でどうして Forbidden にしているのか(リファラの問題なのか、それ以外に原因があるのか)を調査し、クライアントから送信されているリファラが期待通りでないためにそうなっているという事であれば、ここでの質問の題材となるでしょうがその点が明確でない以上、今の時点でここで質問するのはあまり適切でないように思えます。

    現時点でアドバイスできるとすれば、F12 開発者ツールの「ネットワーク」や Fiddler、ネットワーク パケット キャプチャなどでクライアントから実際にどのようなリファラが送信されているのか調査すると良さそう、という位でしょう。


    hebikuzure

    2016年12月28日 10:44
    モデレータ
  • Microsoft コミュニティ「リファラーチェックについて」からの移動のようで、そちらで IE がリファラとして URL のフラグメント部分(# 以降)も送信しているためではないかと書かれていますが、それを本件での実際の挙動として確認されたのでしょうか。

    リファラにはフラグメントを送信しないのが HTTP の RFC(https://tools.ietf.org/html/rfc7231#section-5.5.2)ですので、IE が実際にそういう挙動をするのであれば、

    で報告されている問題である可能性が考えられます。ただこの bug 報告は not repro で close されているので、他に再現条件があるのかもしれません。修正などについての情報が必要であれば、企業向け有償サポートを利用して問い合わせされると良いでしょう。

     


    hebikuzure

    2016年12月29日 7:40
    モデレータ
  • ご返答ありがとうございます。

    フォーラム利用法を把握しておらず不明瞭な質問となり失礼いたしました。

    アプリケーションサイドからは厳密な検証はできないがリファラーチェック設定が影響しているだろうとのことです。実際設定を外すといずれのコンテンツの正常に機能します。

    ブラウザサイドで何か解消されるような要素がないかと思い、ひとまず質問いたしました。

    ご返答を参考にさせていただきます。


    2017年1月4日 1:27
  • 情報のご共有ありがとうございます。

    参考にさせていただきます。

    2017年1月4日 1:38
  • > リファラーチェック設定が影響しているだろうとのことです。実際設定を外すといずれのコンテンツの正常に機能します

    これが正しければ、次に行うべきは実際にどのようなリファラが送信されると撥ねられてしまうのか、先に書いたようにF12 開発者ツールの「ネットワーク」や Fiddler、ネットワーク パケット キャプチャなどで調査していくことでしょう。

    そこが明確になれば、アプリ側の改修要求などもしやすいと思います。


    hebikuzure

    2017年1月5日 6:32
    モデレータ