第91話のreport receiptから、三枚のname cardが起き上がった。
upload.picoroute.test
status.picoroute.test
support.picoroute.test三つとも、右側にpicoroute.testを持つ。
イトはupload gateでもらったsession ringを、三枚へまとめて通した。
「同じ名字なら、同じ建物の同じ鍵だ」
upload gateは開いた。
status gateには鍵穴がない。
support gateはringを返した。
upload request accepted
status request public / no session needed
support request upload session not acceptedイトは、ringを大きなpressへ置いた。
pressの札は、parent-wide。
一つのsessionをpicoroute.test配下へ広げ、三つの入口へ送る装置だった。
「同じ親なら、全部へ届くようにすればいい」
同じ親が示すのは、名前の階層
DNSのdomain nameは、dotで区切られたlabelの階層になっている。
このclosed fixtureでは、三つのnameはすべてpicoroute.testの下にある。
picoroute.test
upload.picoroute.test
status.picoroute.test
support.picoroute.testこの親子関係から、三つの行き先が同じだとは決まらない。
DNS answerを別々に持てる。
別のserviceへ向けられる。
名前空間の一部を別の管理境界へdelegateする構成もあり得る。
反対に、別々のnameが同じIP addressへ向く場合もある。
同じIPだから、同じapplicationやlogin policyだとも決まらない。
ユイ
名前の親子と、実際の行き先は別々に確認するんですね
マコト
同じ親は関係の手掛かり。でもsame serverやsame trustのreceiptではない
イト
名字だけ見て、鍵の範囲まで決めてた
Picoは三枚を重ねない。
dotで区切られたlabelと、その裏にある三本のrouteを別々に照らした。
hostnameが変わると、Webのoriginも変わる
Webのoriginは、基本的にscheme、host、portの組で分ける。
https://upload.picoroute.test/
https://status.picoroute.test/二つはschemeとportが同じでも、hostが違う。
したがって別originだ。
一方、次の二つはhostが同じでpathだけが違う。
https://picoroute.test/upload/
https://picoroute.test/status/pathはoriginの組に入らない。
ただし、別originだから絶対に情報を渡せない、という意味でもない。
serviceが許可した連携や認証の仕組みは作れる。
大切なのは、名前の見た目だけで連携済みだと決めないことだ。
よくある誤解：同じ親ドメインなら同じサイト・同じログイン
Cookieのsession ringには、送るhostの範囲がある。
今回のupload serviceが発行したringには、親全体へ広げるDomain指定がない。
browserはhost-onlyとして扱い、upload hostへだけ返す。
cookie name upload_session
issued by upload.picoroute.test
Domain attribute absent
host-only trueだから、statusやsupportへ自動では送られない。
一方、serviceがDomain=picoroute.testのように親を明示すれば、対応するsubdomainへ送られるcookieも作れる。
つまり、subdomainだから共有されないも万能な式ではない。
共有範囲は、serviceの設計とcookie属性を見て判断する。
範囲を広げれば便利になる場合はある。
同時に、そのcredentialを受け取るhostも増える。
mutually untrustedなserviceへ同じsensitive cookieを広げれば、境界を弱める場合がある。
マコト
共有できることと、共有してよいことは別だ
ユイ
今回必要なのはsupportへの一回の引き継ぎです。三つ全部の常用鍵ではありません
イト
開かない入口へ合わせて、鍵を大きくしすぎてた
残り24秒の三択
upload sessionの有効時間は、残り二十四秒。
supportへreport receiptを一度引き継げればよい。
statusは誰でも読めるpublic情報だ。
uploadの未送信draft二件を失わない。
sensitive credentialをURLへ入れない。
一回用handoffが失敗したら、ticketを使い回さずsupport入口で止める。
イトはringの前に、三本のroute cardを置いた。
イト
A。upload sessionをparent-wideに広げ、三つのsubdomainへ毎回送る
イト
B。upload sessionの文字列をstatusとsupportのURLへ貼る
イト
C。uploadはhost-onlyのまま保ち、public statusと一回用support handoffを分ける
Aは、一回だけ必要な引き継ぎのためにcredentialの受取範囲を広げる。
Bは、sensitive valueをURL、履歴、logなど別の面へ露出させ得る。
Cなら、三つのserviceが必要とする権限を同じにしない。
このone-time handoffはclosed fixtureの設計で、すべてのsiteが持つ共通機能ではない。
イトがparent-wide pressを閉じ、三つの入口を分けた
イトは左手で、parent-wide key pressのamber lidを閉じた。
session文字列をURLへ落とすcopy chuteにもlockを掛ける。
右手で、三枚のname cardを別々のservice gateへ戻した。
status gateは、session ringを受け取らずにpublic panelを返した。
upload gateは、元のhost-only ringを保つ。
イトはupload serviceへ、一回だけsupportへ渡すhandoffを求めた。
fixtureのhandoff ticketは、中身を読めないopaque valueだ。
宛先はsupport serviceだけ。
有効時間は十五秒。
一回受け取られたら、同じticketは閉じる。
イトはURL queryへ貼らず、fixtureのhandoff bodyでsupport gateへ渡した。
Picoは三つのrouteの境界をinspection lightで分離する。
ring、ticket、gate、timerには触れない。
supportは開いた。同じticketは二度開かなかった
support gateからreceiptが返った。
upload_session -> upload sent
upload_session -> status not sent
upload_session -> support not sent
public status received
support handoff accepted 1
same handoff replay accepted 0
upload drafts retained 2support caseには、第91話のreport receiptだけが添付された。
uploadの編集権限は渡っていない。
statusにも、session ringは落ちていない。
イトは、使い終わったone-time ticketを再びsupport gateへ入れた。
gateは開かなかった。
一回用の境界が、観測できる結果になった。
ただしhandoffを作る仕組み、audience確認、expiry、transport、error処理はserviceごとに設計が必要だ。
one-timeという名前だけで安全になるわけではない。
subdomainを見たときの確認順
まずURLをscheme、hostname、port、pathへ分ける。
https://support.picoroute.test/case/92
scheme https
hostname support.picoroute.test
port default for scheme
path /case/92次に、hostname全体を確認する。
このfixtureではsupport.picoroute.testはpicoroute.testの下にある。
picoroute-support.testは、似た文字を持つ別のnameだ。
実際のpublic suffixや登録境界は.testの例より複雑な場合がある。
login、支払い、file uploadでは、見た目の一部だけで所属を決めず、公式導線、browser表示、password manager、組織の案内へ戻る。
名前が親子でも、次を別々に確かめる。
DNS destination
TLS / secure connection
application purpose
credential scope
operator / trust decision不明なhostへcredentialを貼らない。
広いDomain cookieへ手作業で変えない。
service連携が必要なら、運営が用意した正式なhandoff / SSO / support入口へ戻る。
三つのstatusが、二つの色を返した
support caseを閉じる前に、イトはstatusを三つの窓で開いた。
ユイのbrowser resolved / cyan
マコトのbrowser resolved / cyan
イトのbrowser incident / amberhostnameは三人とも同じ。
network traceでは、イトのbrowserにもfresh responseが届いている。
それでも画面には、前に見たamber panelが残っていた。
イトはcookie boxとimage shelfをまとめて大きなdelete trayへ入れた。
「古いなら、全部消せば新しくなる」
ユイは、uploadのhost-only ringと未送信draftを見た。
一つの表示を直すために、何を消そうとしているのか。
イトはdelete trayを止め、cookie boxとcached panelを二つの棚へ戻した。
次回、ピコルート第93話。
イトは、古いstatusを直すためにログインまで消す？｜キャッシュ削除の境界