認証と認可
いまの fleama は誰でも操作できる
第6章までで、出品も購入も削除もできる API ができました。ですが問題があります。
誰が呼んでも通ります。 他人の商品を勝手に書き換えることも、消すこともできます。フリマとしては成り立ちません。
第7章では、この穴を塞ぎます。
2つの別々の問い
必要なことは 2 つあり、混ざりやすいので分けて覚えてください。
| 問い | 例 | |
|---|---|---|
| 認証 | あなたは誰か | ログインして本人だと確かめる |
| 認可 | それをしてよいか | 自分の商品だけ編集できる |
認証が先で、認可が後です。誰だか分からないうちは、してよいかも判断できません。
順番に見ていく
出品を書き換える依頼が来たとき、確かめるのはこの順です。
プレーンテキスト
1. ログインしているか → していなければ 401
2. その商品の出品者か → 違えば 403
3. その商品は存在するか → 無ければ 404401 と 403 の違い
どちらも「断る」ですが、意味が違います。
| コード | 意味 | 言い換えると |
|---|---|---|
| 401 | 誰だか分からない | ログインしてください |
| 403 | 誰かは分かるが、権限が無い | あなたには許可されていません |
401 はログインすれば通ります。403 はログインし直しても通りません。他人の商品は、誰としてログインしても他人の商品だからです。
この 2 つを取り違えると、受け取った側が「ログインし直せば直るのか」を判断できなくなります。
認証はミドルウェアの仕事
第5章で「共通処理は手前にまとめる」と学びました。認証はまさにそれです。
プレーンテキスト
リクエスト → 認証ミドルウェア → ルート通してよければ next()、だめなら 401 を返して打ち切ります。next() を呼ばずに止めるのが正しい場面が、ここで出てきます。
手を動かす
演習では、いまの状態を確かめます。守られていない API に何が起きるのかを、自分の目で見てください。
要件
userが空なら 401(ログインしていない)userがownerと違えば 403(権限が無い)existsが false なら 404、すべて問題なければ 200
入出力例
judge("田中", "田中", true) → 200
judge("", "田中", true) → 401
judge("鈴木", "田中", true) → 403
judge("田中", "田中", false) → 404
judge("", "田中", false) → 401ヒント
編集 ゆめさく編集部