OpenResty Edge を使用してウェブサイトで SSL を強制する
今回は、ウェブサイトで SSL を強制する方法をご紹介いたします。つまり、すべてのユーザーの HTTP リクエストを対応する HTTPS にリダイレクトする方法です。
HTTP リクエストをリダイレクトするページルールの作成
いつものように、OpenResty Edge の Admin Web コンソールにアクセスしましょう。これはコンソールのサンプルデプロイメントです。各ユーザーには独自のローカルデプロイメントがあります。
今回も test-edge.com ドメインのサンプルアプリケーションを使用します。
このアプリケーションに移動します。
次に、ページルールのページに移動します。
新しいページルールを作成します。
すべての HTTP リクエストに対してルール条件を有効にします。
まず、選択可能なすべての変数を確認しましょう。
Scheme を選択します。
文字列等号演算子はそのままにしておきます。
次に、値として http を選択します。
これで条件が完成しました。すべての HTTP リクエストにマッチし、HTTPS リクエストは除外されます。
次に、ルールのアクション部分では、301 リダイレクトアクションを設定できます。
ここには多くのアクションがあります。
そのため、Redirect アクションを直接検索するのが最適です。
これを選択します。
現在のリクエスト URI はそのままにしておきます。
また、現在のリクエストの URI パラメータまたはクエリ文字列も引き継ぎます。
ただし、新しいリクエストのスキームは変更する必要があります。
https を選択します。
ここで 301 リダイレクトを代わりに選択できます。
これは「永続的リダイレクト」を意味します。
このルールが既存の通常ルールの前に実行されるようにする必要があります。
このルールがマッチした場合、後続のルールをスキップするようにします。
このルールに関しては実際には必要ありませんが、リクエストの処理を即座に停止したい場合は、明示的に指定することが常に良い方法です。
これでルールを作成します。
ここで、すべての HTTP リクエストを対応する HTTPS リクエストにリダイレクトする新しいページルールが表示されます。
いつものように、この新しいページルールをプッシュするにはリリースする必要があります。
このボタンをクリックします。
リリースします!
完全に同期されました。
これで、新しいページルールがすべてのゲートウェイクラスターとサーバーにプッシュされました。
この設定変更では、サーバーのリロード、再起動、またはサーバープロセスのバイナリアップグレードは必要ありません。そのため、非常に効率的でスケーラブルです。
ページルールのテスト
新しいブラウザのタブを開き、HTTP で test-edge.com ウェブサイトにアクセスしてみましょう。
実際に HTTPS に変更されていたことがわかります。ブラウザのアドレスバーの小さな鍵アイコンに注目してください。
ターミナルでも curl を使用してテストできます。
curl -Ss -I http://test-edge.com/
確かに 301 リダイレクトで、HTTPS プロトコルを使用しています。
より複雑な URI とクエリ文字列も試してみましょう。
curl -Ss -I 'http://test-edge.com/foo/bar?a=32&b=56'
依然として HTTPS にリダイレクトされていることがわかります。
また、URI とクエリ文字列も保持されています。
よくある質問
HTTP から HTTPS へのリダイレクトは 301 と 302 のどちらを使うべきですか?
OpenResty Edge の Redirect アクションは既定で 302(Moved Temporarily) になっており、ステータスコードのドロップダウンには 301、303、307 も用意されています。HTTPS を強制する場合は 301(Moved Permanently) に変更してください。サイトを HTTP から HTTPS へ移すのは一時的な変更ではなく恒久的な変更なので、永続的リダイレクトが正しい表現です。
リダイレクトは元の URI とクエリ文字列を保持しますか?
はい。Redirect アクションで URI と URI arguments を current のままにし、Scheme だけを https に変更します。すると http://test-edge.com/foo/bar?a=32&b=56 は HTTPS の同じパスとクエリ文字列にリダイレクトされます。本記事の curl -Ss -I テストでも、Location ヘッダーが両方をそのまま引き継いでいることが確認できます。
このルールは HTTPS リクエストもリダイレクトしますか?
いいえ。ルール条件は Scheme 変数を http と文字列等価で判定するため、すべての HTTP リクエストにマッチし、HTTPS リクエストは除外されます。すでに HTTPS で到達したリクエストは条件にマッチせず、通常のルールにそのまま渡されます。
リダイレクトを適用するにはゲートウェイの再起動や再読み込みが必要ですか?
いいえ。ルールを作成したあと新しいリリースを行えば、ルールはすべてのゲートウェイクラスターとサーバーにプッシュされます。OpenResty Edge の設定変更はサーバーの再読み込み、再起動、バイナリアップグレードを必要としません。これが大規模なクラスターにリダイレクトを展開しても効率的である理由です。
なぜこのリダイレクトルールを他のページルールより前に実行すべきなのですか?
既存の通常ルールより前に配置し、マッチした際に後続のルールをスキップするかどうかを決めます。このルールに関しては必須ではありませんが、リクエストの処理を即座に停止したい場合は、明示的に指定することが常に良い方法です。
著者について
章亦春(Zhang Yichun)は、オープンソースの OpenResty® プロジェクトの創始者であり、OpenResty Inc. の CEO および創業者です。
章亦春(GitHub ID: agentzh)は中国江蘇省生まれで、現在は米国ベイエリアに在住しております。彼は中国における初期のオープンソース技術と文化の提唱者およびリーダーの一人であり、Cloudflare、Yahoo!、Alibaba など、国際的に有名なハイテク企業に勤務した経験があります。「エッジコンピューティング」、「動的トレーシング」、「機械プログラミング」 の先駆者であり、22 年以上のプログラミング経験と 16 年以上のオープンソース経験を持っております。世界中で 4000 万以上のドメイン名を持つユーザーを抱えるオープンソースプロジェクトのリーダーとして、彼は OpenResty® オープンソースプロジェクトをベースに、米国シリコンバレーの中心部にハイテク企業 OpenResty Inc. を設立いたしました。同社の主力製品である OpenResty XRay(動的トレーシング技術を利用した非侵襲的な障害分析および排除ツール)と OpenResty Edge(マイクロサービスおよび分散トラフィックに最適化された多機能ゲートウェイソフトウェア)は、世界中の多くの上場企業および大企業から高い評価を得ております。OpenResty 以外にも、章亦春は Linux カーネル、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl など、複数のオープンソースプロジェクトに累計 100 万行以上のコードを寄与し、60 以上のオープンソースソフトウェアライブラリを執筆しております。
翻訳
英文版の原文と日本語訳版(本文)をご用意しております。読者の皆様による他の言語への翻訳版も歓迎いたします。全文翻訳で省略がなければ、採用を検討させていただきます。心より感謝申し上げます!



















































