未認証の配布ページが401で拒否されることを確認しました。配布物の署名済みハッシュも確認済みです。それでも、利用者がスマートフォンで案内されたリンクを開くと、画面にはUnauthorizedと表示されました。
境界は閉じていました。しかし、更新は届いていませんでした。
認証済みのアプリ、チャット内ブラウザ、外部ブラウザ、PWA、端末の操作環境は、同じcookieを共有するとは限りません。未認証の401はprivacy gateとして正しくても、利用者が実際に通る受け取り導線にとっては行き止まりになります。
ここで必要なのは、拒否試験を緩めることではありません。「安全な拒否」と「利用者の成功」を、別々の完了条件として検証することです。
401が正しくても、配布は完了していない
今回の観測では、公開ヘルスは200、未認証の配布ページと配布物は401でした。つまり、公開すべきでないものを誰にでも渡してはいない、という確認はできています。
一方で、案内リンクを利用者側のブラウザで開いた場合は認証文脈がなく、受け取りに失敗しました。監視やサーバー側の試験だけでは、「実際にリンクを開く場所」を再現できなかったためです。
無人運用では、サービスを動かし続ける土台と、利用者が成果を取り出せる入口を分けて考える必要があります。前提となる常時稼働・遠隔・監視の考え方は、仕事中も自宅ラボが回る土台：常時稼働・WoL・遠隔・監視の組み合わせでも整理しています。今回は、その先にある「成果を渡し切る」地点の検収です。
完了条件は二列に分ける
安全性と利便性を一つのチェック項目に畳むと、どちらかを見落としやすくなります。確認する対象を分けます。
| 確認したいこと | 安全な拒否 | 利用者の成功 |
|---|---|---|
| 誰が試すか | 権限のないアクセス | 正しい案内を受け取った利用者 |
| 入口 | 配布ページ・配布物への直接アクセス | 固定された案内入口 |
| 期待する結果 | 範囲外は401 | 入口から配布物取得まで到達 |
| 再利用への対応 | 不正な再利用を通さない | 正規の一回の操作で迷わせない |
| 検収の意味 | 境界が閉じている証拠 | 価値が届いた証拠 |
両方が必要です。未認証の拒否だけでは「漏れない」ことしか分かりません。利用者導線だけでは「渡せる」ことしか分かりません。
監視設計でも、何を測り、何に通知するかを目的ごとに分離します。監視の部品表 — 何を入れ、何に鳴らすか（最終回）で扱った条件設計と同じく、拒否と成功は代替関係ではありません。
URLに長期の認証情報を置かない
別ブラウザへ渡すために、長期の認証情報をURLへ含める方法は一見簡単です。しかしURLは履歴、参照元、ログなどに残り得ます。受け渡しの手軽さのために、長く使える権限まで一緒に運ばないほうがよいでしょう。
復旧では、端末側で発行する256-bitの短命ticketを用いました。有効期限は10分、交換は1回だけです。ticketは配布先に限定したcookieへ交換し、配布ページと配布物だけを利用できるようにしました。
これは特定の実装を勧める話ではありません。一般化すると、受け渡し用の権限は次のように絞る、という原則です。
- 用途を配布だけに限定する
- 有効時間を短くする
- 交換回数を限定する
- 秘密値そのものを保存せず、照合用の値で扱う
- 認証情報をURLやログに残さない
「認証を移す」のではなく、「受け取りのためだけに狭めた権限を一度交換する」と考えると、判断がぶれにくくなります。
一度通った復旧と、日常導線の完成は別です
最初の復旧では、ticketの交換が303、配布ページと配布物が200、範囲外が401、ticket再利用が404、未認証配布が401となることを確認しました。server testは203件、ビルド、自己試験、独立review、仮環境でのHTTP integrationも通過しています。
ここまでで、安全に一度受け取れる経路はできました。ただし、毎回の更新で利用者が複数の手順を意識するなら、日常の体験としては未完了です。
後続の検証では、固定の入口から認証交換、配布ページ、配布物取得までを一続きで確認しました。server testは209件、web testは5件で、両方のビルドと仮環境・公開環境のHTTP matrixを通しています。固定導線でも、配布に限定したcapabilityを使い、同一オリジンの64-byte POSTが成功した場合だけ、30分有効で配布先限定のcookieを発行する構成です。
非常時に一度だけ成功する手順と、更新のたびに迷わず使える手順は同じではありません。利用頻度と操作回数を含めて、入口は固定し、更新ごとに変わる要素は配布物側へ閉じ込めます。この区別を入れると、自動化の「動いた」は「使える」へ近づきます。
自分の配布導線を検収する質問
配布を自動化しているなら、次の二つを分けて確認してください。
- 別のブラウザでリンクを開いた利用者は、迷わず必要な成果を受け取れるか。
- 未認証・範囲外・再利用の試験を、利用者の成功試験とは別に通したか。
完了は「拒否できた」ではなく、「正しい利用者が、正しい導線で、必要な成果を受け取れた」までです。
境界を閉じる検証は欠かせません。ただし、最後の検収者は導線を歩く利用者です。そこまで確認して初めて、配布の自動化は静かに役目を果たします。
この検証を回している環境
この検証は、自宅の常設ラボ（使い捨てVM/LXCを回す母艦＋GPU＋VLAN分離ネットワーク）で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。
ラボ構成のまとめを見る →
