CloudFrontとOAuth認証が必要なElasticBeanstalkの連携

ElasticBeanstalkで作ったWebアプリ環境（Devise+omniauth入）をELBで受けるのではなく一旦CloudFrontで受けるためにどんなとこに苦労したかの記事です。

Webアプリケーションの環境

• rails
  • 認証系にはDeviseを利用
    • Googleアカウントと紐付けている(重要)
  • cookieを使ってる（重要）
  • ElasticBeanstalkをつかっている
  • あるパスへのアクセスはAPI Gatewayに流す

苦労した点１：CloudFrontとELBの証明書の違い

SSL Certificateには*.yasai.comで設定されていたとします。

Create OriginでWebアプリ環境への設定を施します。

間違い

ここで、使われているELBが選択肢現れるからといって、そのまま選んではいけません。

なぜなら、CloudFront -> ELBで参照するのはhogehoge.ap-southeast-1.elb.amazonaws.comなので、全くドメインが合っていません。

正解

ここはちゃんとRoute53でELBのエンドポイントに対し、 tomato.yasai.com の名前でとってあげて、下記のように設定すべきです。

苦労した点２：GoogleへのOAuthの失敗、ユーザーが全然ログインできない

結論からいうと、CloudFrontのキャッシュはちゃんとしようということになります。

• なぜユーザーがログインできなかったか？
  • CloudFrontはCookie情報をWebアプリに送っていなかった
• GoogleのOAuth認証が失敗した
  • ここは詳しく調べれてないのですが、callbackでWebアプリに戻ってくるときに失敗が発生していました。queryやHeaderなどのキャッシュが原因と見ていますが断定はできません。

なので、どのheader,query,cookieならWebアプリに送っていいか、なにをキャッシュすべきか適切に設定しましょう。
私は今回CloudFrontの役割はキャッシュではなかったので、 ちょこちょこ設定するのはさすがにめんどくさすぎたので ほぼキャッシュさせないようにしました。

苦労した点３：API GatewayとCloudFrontとの連携は気をつけるべし

これは前述のWebアプリにCookie情報やheader情報を送っていたのに対して、API Gatewayに対してはなんでもかんでも送ってはいけません。

この記事にもある通り、Host情報をCloudFrontからAPI Gatewayに送っていたために正常な動作をしませんでした。