認可は3つの問いでできている

所有者は「データの探し方」で確かめる

講座31の第3回で見たとおり、IDだけでデータを探すと、IDを書き換えられたときに他人のデータが出てきます。「持ち主の中から探す」形にしておけば、判定を書き忘れることがありません。

ログインしていない人のデータでは、どうでしょう。naminori の AIキャリア診断は、登録しなくても答えられます。持ち主は次のように確かめています。

• 診断を始めたときに、長いランダムな秘密の値を作る
• ブラウザには、暗号化した Cookie で渡す。JavaScript からは読めず、HTTPS でしか送られない設定にする
• サーバーには、秘密の値そのものではなく照合用の値だけを保存し、診断は秘密の値で探す。だから、診断の番号を書き換えても他人の診断は出てこない
• 会員登録・ログインしたら、診断を会員に結びつけて Cookie を消す。以後は「会員の持ち物」として探す

ロールと権限を分ける

画面のコードが「この人は管理者か」を直接聞くと、ロールが増えるたびに全部の判定を直すことになります。間にロールから権限を引く表を1つ置きます（Ruby で確認）。

PERMISSIONS = {
  viewer: %i[read],
  editor: %i[read update],
  owner:  %i[read update delete]
}.freeze
def can?(role, action) = PERMISSIONS.fetch(role, []).include?(action)

can?(:viewer, :update)  # => false
can?(:editor, :update)  # => true
can?(:unknown, :read)   # => false

画面のコードは「この操作をしてよいか」だけを聞きます。ロールを足すときは表に1行足すだけです。表に無いロールは何もできません（既定は拒否）。

後から困ること

• 管理者を真偽値1つで作る。 半年後に「閲覧だけの管理者」「求人だけ直せる人」が必要になると、全画面に散らばった「管理者なら」の判定を1つずつ書き換えることになります
• 判定を画面ごとに書く。 API や AI アプリの接続など新しい入口を足したとき、そちらで判定が漏れます
• 既定を「許可」にする。 新しい画面を足して判定を書き忘れると、誰でも使えます

naminori の例：判定を1か所に集める

naminori の管理用の AI 接続では、どの操作も同じ1か所の判定を通ります。順番は次のとおりです。

1. そのデータは、AI から触れてよい対象か
2. この接続に許された範囲か
3. 書き込みなら、そのデータが書き込める対象で、接続の段階で許されているか
4. 削除なら、そのデータが削除してよい対象か（消すと利用者のデータまで連鎖して消えるものは消せない）

接続の段階は「参照のみ／作成・更新まで／削除まで」の3つで、段階から「できる操作」を引く形にしています。

• 所有者・ロール・権限の3つの問い
• ログインしていない人の持ち主を確かめる（naminori の診断）
• ロールから権限を引く表を1つ置く（手元で確認）
• 判定を1か所に集め、既定は拒否にする