Auth0でユーザーがMFAの設定をしている時のみMFA検証フォームを出す

ユーザー設定画面にMFAの設定画面があり、それが設定されているときだけログイン後にMFAのフォームを出したいという要求はよくある。これをAuth0を使っている場合に達成したかった。しかし、Enable Multi-Factor Authenticationなどを見ても、全体に有効/無効しか切り替えられないようで困っていた。

いろいろ調べたところやる方法が分かったのでメモしておく。

ユーザー向けのMFA設定画面を自分のアプリケーションに実装する方法

まずユーザー向けのMFA設定画面を自分のアプリケーションに実装するには、Auth0のMFAリソースに対する権限を持ったアクセストークンを取得する必要がある。詳しくはManage Authenticator Factors with Auth0 MFA APIに書かれているが

• Auth0のApplication設定画面でGrant TypesにMFAを追加
• ログインなどのリクエスト時に、audienceの指定を https://YOUR_DOMAIN/mfa/とする。さらにScopesを適切につける。関係するのはenroll, read:authenticators, remove:authenticatorsの三つ

これで取得したアクセストークンであれば、MFAのenrollや登録したMFA認証の一覧取得などをAPI経由で行えるようになる。このAPIを使ってユーザー向けの設定画面を実装すれば良い。

MFAを設定している場合だけログイン後にMFA検証フォームを出す

Auth0 ActionsやAuth0 Rulesを使う必要がある。自分はActionsを使って実装してみた。

event.user.multifactorにユーザーがenrollしているMFAのプロバイダ一覧が入っているので、一つでも設定していたらフォームを出すようにする。以下のコードで可能。

exports.onExecutePostLogin = async (event, api) => {
  if (event.user.multifactor && event.user.multifactor.length > 0) {
    api.multifactor.enable(“any”)
  }
};

git grepの結果に、その行を書いたAuthorを表示する

あまり知らないコードを触るときに、周りのコードを参考にしたいことが多い。しかし、そのコードの技術スタックに詳しくない場合、どのコードは筋が良いかというのが全く分からないことがある。そういう時に、その分野に知見がある人が書いたコードを参考にしながら学習したい。

そのように知見を素早く吸収するために、git grepの結果に、その行を書いたAuthorを表示するとどうかと思ったのでやってみた。

git-grep-with-author

#!/bin/bash

git grep -n "$@" | while IFS=: read i j k
do
  author=$(git blame -L $j,$j $i --line-porcelain | grep '^author ' | cut -d' ' -f2-)
  echo -e "$i:$j:$author:$k"
done

例えばRailsのrepositoryで使うと

$ git-grep-with-author ActiveModel
actionpack/lib/action_controller/metal/params_wrapper.rb:52:Prem Sichanugrist:  # If you're going to pass the parameters to an +ActiveModel+ object (such as
actionpack/lib/action_controller/metal/strong_parameters.rb:260:Francesco Rodriguez:    #   Person.new(params) # => ActiveModel::ForbiddenAttributesError
actionpack/lib/action_controller/metal/strong_parameters.rb:424:Francesco Rodriguez:    #   Person.new(params) # => ActiveModel::ForbiddenAttributesError
actionpack/lib/action_controller/metal/strong_parameters.rb:873:Prem Sichanugrist:    # This is required by ActiveModel attribute assignment, so that user can
actionpack/lib/action_controller/metal/strong_parameters.rb:1157:yuuji.yaginuma:  #     # ActiveModel::ForbiddenAttributesError exception because it'd
actionpack/test/controller/redirect_test.rb:6:Jon Moss:  extend ActiveModel::Naming
actionpack/test/controller/redirect_test.rb:7:Jon Moss:  include ActiveModel::Conversion

のようにファイル名と行の後に、Authorを出してくれるようになった。便利。

「Scaling Teams 開発チーム 組織と人の成長戦略」を読んだ

開発組織をスケールする方法を学びたい - 「ユニコーン企業のひみつ」を読んだ - $shibayu36->blog;に引き続き、開発組織が拡大しても、一人当たりの生産性を落とさずに、かつ顧客にとって本当に必要なものを作り続けるにはどうしたら良いのかのヒントを得るために、「Scaling Teams 開発チーム 組織と人の成長戦略」を読んだ。

Scaling Teams 開発チーム 組織と人の成長戦略 (Compass Booksシリーズ)

めちゃくちゃ良かった！この本では、組織のスケールで重要な局面を採用・人事管理・組織・文化・コミュニケーションの5つとし、それぞれに対して何を気をつけるべきかについてまとめてくれている。特に自分の興味と合致する「採用」「組織」の部分は本当に参考になった。例えば「組織」のところで組織構造を考える原則について紹介されているのだけど、非常に端的にまとまっていて印象に残った。

• 組織構造を設計する際に忘れてはならない2つの重要な目標 3105
  • 小規模組織の敏捷性をいつまでも失わず、作業を素早く進められる組織構造
  • 社員一人一人を製品とその成功に直結させる
• 組織設計の原則 3107
  • デリバリーチームの構築：着想から公開まで全てに必要な職能をもれなく備えた自立型チームを作る
    • 未処理案件の大部分（最高で95%）を他チームに依存せずに本番環境に移せるチームが、真の意味で「自立型」と呼べる 3185
    • 大規模プロジェクトの臨時チームの立ち上げの時も同じように行う
  • 自律性の確保：割り振られた目標を最良の形で達成するためにはどのような行動を取るべきかを自決する権限をチームに与え、選択したアクションの影響を必ず測定させる
    • 自律性とは、一定の制約の範囲内で、どの作業を進めるかを決める自由をチームが有すること 3227
      • 制約とは、ビジネス上の優先度、組織全体の目標、チームの権限など。チーム間の足並み揃えにはこの制約は必要
    • チームの自律性がより広範な戦略的目標のために無視されてしまうことがあるが、次の2点は守りたい 3280
      • チームは常に少なくとも勤務時間の半分を自由に使えるように。戦略的な取り組みは半分まで
      • ただし例外として、戦略的な取り組みの中でそのチームがボトルネックになっているなら、チームは作業時間の全てを使ってでもボトルネックの解消に努める
  • 目的の明確化と成功度の測定：どのような目標を掲げれば前者レベルの成功に最も寄与できるかを把握する必要がある
  • 継続的デリバリー：フィードバックを頻繁に得られ、製品の質の向上や顧客思考の思考が定着する。短期間で成果を反映できるためチームの満足度も高まる。市場投入までのリードタイムを減らせる
  • 継続的学習を重視する文化の醸成：振り返りと改善をし続ける
• 自立型チームを柱にした編成に付き物のリスクは二つ 3679
  • チーム間コラボレーション不足、スケールメリットが見込めなくなる
  • Spotifyでは横の繋がりを作るための仕組みを用意

こんな感じで学びが多いのでおすすめです。