煙と消えるその前に

一服してるうちに忘れる、自分のための備忘録。とかとか

AWS ALBのルーティングに認証を入れたら500エラーになった時

Webアプリを開発しているとき、ステージング環境を作ることって多いと思う。
で、ステージングは外部からアクセスされたくないので何かしら制限をかける。
昔はnginx/apacheで認証してみたり、クライアント証明書を作って配布したり、アクセス元IPでフィルタしていたのだけど・・・
今だとAWS ALB + Amazon Cognitoで楽に実現できる!

Application Load Balancer 組み込み認証によりログインを簡略化 | Amazon Web Services ブログ

何これ、超簡単。
しかもマネコンから操作できるし、小規模開発なら無料枠で十分収まる。

意気揚々と設定して、実際に動かしてみたらログイン画面出ましたわー
f:id:paty_fakename:20190130140513p:plain

Cognitoで作成したユーザでログインしてみると・・・
f:id:paty_fakename:20190130140600p:plain

?!?!
なんてこと・・・。
フロントエンドすらログが出ていない。
ALBのログを取ってみたところ、ここで止まってらしい。

さて困ったとドキュメントを漁ってみたら、やっぱりありますよね
Application Load Balancer のトラブルシューティング - Elastic Load Balancing

いくつかケースが書いてあるけど、おそらくALBが外部と通信できていない様子。
VPCにはinternet gatewayとルーティングを設定していたけど、SecurityGroupのアウトバウンド設定が漏れていた。
ElasticBeanstalkで生成したデフォなやつを使っていたせいで、443のルーティング設定が不十分だったのが原因。
とても単純な話なんだけど、マネコンぽちぽちで500エラーに遭遇すると面食らうなー。

git bad default revision 'HEAD' に困ったので手動修正したけど不安しか残らなかった

VirtualBox上のCentOSで開発をしていて、ある日VMがフリーズしたので渋々強制再起動したらローカルリポジトリが壊れた。
表題のエラーが出たのでとりあえず修復したが、完全に直っているか不安で結局リポジトリをcloneし直したという記録。

gitコマンドが軒並み失敗する

$ git status
fatal: bad default revision 'HEAD'

$ git log
fatal: bad default revision 'HEAD'

!?
どういうことやと思ってHEADの中身を見てみる

$ cat .git/HEAD
ref: refs/heads/mybranch

よしよし、直近で作業してたブランチのままだ
ブランチのファイルを念のため確認

$ find -name *mybranch*
./.git/refs/heads/mybranch
./.git/refs/remotes/origin/mybranch

ファイルはあるなー
中身どうなってんだろ

$ cat .git/refs/heads/mybranch
(空)
$ cat .git/refs/remotes/origin/mybranch
(空)

あー何も無い
HEADコミットのSHAが取れないからエラーになってるのかな
リモートからブランチの最新コミットを見つけて手動で埋めてみる

$ git ls-remote origin mybranch
リモート上の最新SHA	refs/heads/mybranch

$ echo -n "リモート上の最新SHA" > .git/refs/heads/mybranch

とりあえずこれで動くようにはなったけど...
VMフリーズの影響で一部ファイルが壊れていたようで、他にも影響が残っている可能性があるし、
手動でファイル書き換えているので完全に直っている保証もないんだよなー
で、結局不安だらけだったのでリポジトリをcloneし直した。

あれこれ終わってから気づいたけど、せめてファイルが編集状態のまま残っているか確認して退避させればよかった
気持ち悪いからと、後腐れなく削除した後だった...

Railsでrender前に共通処理を入れたくて

一覧表示をする際に、ログインユーザに応じて一覧をカスタマイズしたかった。
複数コントローラで同じ処理が必要だったのでafter_actionで実装してみたけど期待通りに動かない!なんでさ!
と思ったら、renderの後にafter_actionが実行されるというオチでした。
で、render前に処理を入れる仕組みないんだっけ?と調べたんだけど、結局自前実装するオチに。

renderをオーバーライド

ぱっと思いついてセルフ却下。
アクション判定しないといけないしイケてないよなーと思ったから。

class IndexCustomizedController < ApplicationController
  def customize
    ...
  end

  def render(*args)
    customize if @_action_name == "index"
    super
  end
end

before_render

あーこれこれ、やっぱりあるよね。
Rails5系の情報が見つからなかったけど参考にできそう。

思いとどまって自前実装

いやでもちょっと待てよ
フレームワークに手を入れてまでやることか...?と思いとどまった。
(AOP的にはrender前もフックポイントと認識されるんだろうか?)
しかもbefore_renderがあると、コードを読むときにその存在を覚えて読まないといけないので*_actionとは違って可読性も落ちそう。
ということで結局moduleを定義することにした。

class MyController < ApplicationController
  def index
    ...
    custom_data = IndexCustomizer.costom(user, data)
    ...
  end

  ...
end