- ログインしていない人を「はじく」考え方が分かる
- 「サーバーはクライアントを信用しない」の意味が分かる
- なぜそれが大事なのか、自分で言える
Phase 7 のまとめの回。ここまでで作ってきた「枠組み」が、ぜんぶそろいます。
入口でチェックする
まず言葉から。クライアントは自分のブラウザ側、サーバーは遠くにあって全員の相手をするコンピューター。やりとりは、クライアントがお願いして、サーバーが返す形です。
「ログインした人だけのページ」は、そのページのいちばん最初でチェックします。「ログインしてる?してなければ、ログイン画面へ」と。これを 擬似コード(考えを言葉のまま書いたもの)で書くと、こんなイメージ。
if (ログインしていない) {
ログイン画面を見せる
}
ログインしている人だけが、その先の中身を見られる。これが入口のチェックだね。
サーバーはクライアントを信用しない
もっと大事な話。クライアント(自分のブラウザ)は、書きかえられるから、送られてきた値をそのまま信じてはいけません。
九九アプリを思い出そう。もし答え合わせをブラウザ側だけでやって「正解でした!」とサーバーに送ると、わるい人はその「正解!」をウソに書きかえて送れてしまう。だから九九アプリは、送られてきた答えをサーバー側でもう一度正誤を判定し直してから保存しています。
// サーバー側でもう一度たしかめる
isCorrect: chosen === dan * multiplier
つまり「送られてきた値をうのみにしない」。これが「サーバーはクライアントを信用しない」という、ずるを防ぐための大事な約束です。
- ログアウトした状態で
/kukuを開いてみる。中身ではなくログイン画面が出るね。これが「入口のチェック」だよ。 app/api/kuku/attempts/route.tsを開いて、サーバーで正誤を判定し直している所を探す。(見つからなければ AI に「どこで再判定してる?」と聞いてみよう)- なぜ「ブラウザだけの判定」ではダメなのか、自分の言葉で説明してみる。
💡 AIと考えよう:「もしサーバーがクライアントを信用したら、どんなズルができる?」と聞いて、いくつ思いつくか出してみよう。
- ログイン必須は、どこでチェックする?(→ ページや API の入口)
- サーバーはクライアントを?(→ 信用しない)
- なぜ正誤を再判定するの?(→ ズルを防ぐため)
これで枠組みが一周そろった! つぎの Phase 8 からは、いよいよ自分のアプリを作っていくよ。