AWS
elb
Beanstalk
CloudFront
Gateway

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

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

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

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

苦労した点1:CloudFrontとELBの証明書の違い

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

スクリーンショット 2018-03-22 14.29.31.png

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

間違い

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

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

スクリーンショット 2018-03-22 14.34.56.png

正解

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

スクリーンショット 2018-03-22 14.58.23.png

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

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

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

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

スクリーンショット 2018-03-22 15.07.29.png

スクリーンショット 2018-03-22 15.07.23.png

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

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

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