phx.gen.auth

Phoenix アプリの認証基盤ジェネレータを使ってみていた。

https://hexdocs.pm/phoenix/mix_phx_gen_auth.html

動かしてみておもしろいことはもとより、パブリシティや設計文書を読むのがおもしろい。

というのも、 Elixir の父たる José は、それに先立つプロジェクトのひとつとして devise gem の設計責任者も兼ねていたためである。それはすなわち、 devise プロジェクトのよい部分と悪い部分をもっともよく熟知するハッカーが、 Phoenix のために認証基盤をゼロから設計したということであって、おおいに注目するに値する。この文書がそのような背景を手短にスケッチしている。

https://dashbit.co/blog/a-new-authentication-solution-for-phoenix

「最高の認証フレームワークは、フレームワークを持たないこと」と力強く宣言している。それを言ったうえで、 devise を省みた述懐がおかれる。

devise は機能モジュールの抽象化に成功したはいいものの、それによってその下にあるデータ構造とロジックをアプリケーションから完全に隠蔽してしまった。コールバックの定義やコントローラの継承によって強力なカスタマイズができることと引き換えに、 devise による認証システムはしばしば過度な複雑さを持つようになった。あらゆる設定の組み合わせのもとで安全な認証がおこなわれることを監査することは困難となってしまった。そういっている。

Phoenix のための認証モジュールは、認証のための API をライブラリとして切り出さないことにした。代わりに Phoenix チームは phx.gen.auth を提供する。これによって、認証ロジックのメンテナンスは完全なホワイトボックスとしてアプリケーション開発者に委ねられる。もちろん、自由と責任を同梱した形で。

ジェネレータによって生成したコードをメンテナンスするということは、ライブラリをアップデートするだけではアップストリームでの改善の恩恵を受けられないということである。自分たちの認証基盤として正しくメンテナンスを継続しなければならない。

いっぽうで、ジェネレータが提供するデータ構造と API は、そこまで激しく晦渋ではない。簡単ではないけれど、（いまのところ） devise よりもずっとシンプルな構造をしている。 users_tokens というテーブルの設計にすべてが集約されている、という印象がある。

この夏から仕事では認証基盤のメンテナンスとマイグレーションを任せてもらっている。アプリケーションと深く結合した devise のロジックを同僚たちとウンウン唸りながら読み解くシーンが何回もあった。おかげで warden と devise には明るくなったものの、苦しい仕事のひとつであったことはたしかだ。

José のステートメントは、そう言われてみるまで気づくことができなかった正しいことを言っているようにおもう。すなわち、アプリケーションの実装のある大きな一部分をライブラリに委ねることは構わないが、ビジネスドメインの中枢に位置するデータと機能は委ねるべきではないということ。そして認証機能はそのもっとも代表的な例であること。

そしてフレームワークは、「だからみなさん、がんばってください！」と問題を引き渡すかわりに、もっともシンプルなテンプレートのジェネレータをユーザーに与える。注意すべき攻撃のサンプルに言及しながら、最低限の要件の輪郭を描写する。実際、このときの「最低限」のレベルはかなり高い。

Phoenix は Rails よりも大量のファイルと API を生み出すジェネレータを持っていて、慣れない身体にはなにかと大量のボイラープレートコードに押しつぶされるような気持ちにさえなることもある。しかしそれはすべて、フレームワークがビジネスロジックの所有権を侵害せず、アプリケーションにそれを持たせようと努めてくれていることの裏返しらしい。

コードは少ないがそのぶん隠蔽されたロジックが多いことよりも、コードは多くともロジックが自明になることを選んでいるような。素早いプロトタイピングの先の世界をみつめているような。少なくとも、ライブラリとはどう扱うものかということを、あらためてよく考えるよう促されているようだ。