第93話でcacheを直しても、upload tabはsigned-inのままだった。
次の利用者へlab browserを渡すまで、二十秒。
イトはcookie boxから、upload_sessionの受付札を一枚取り出した。
local delete slotへ差し込み、preview leverを半分まで引く。
after local cookie deletion preview
browser cookie present 0
next Cookie header absent
server session active 1
account exists 1
server drafts 2browserは次のrequestで、その受付札を送らなくなる。
画面はlogin入口へ戻るかもしれない。
でもserver側のcurrent sessionは、まだactiveだった。
「受付札が消えたら、部屋の鍵も閉じたことになると思ってた」
イトの手は、preview leverの上で止まった。
Cookieは、browserがserverへ返す小さなrecord
serverはHTTP responseのSet-Cookieで、user agentへcookieを保存するよう求められる。
browserはscopeに合う後続requestで、そのcookieをCookie headerへ入れる。
server -> Set-Cookie -> browser storage
browser -> Cookie -> server requestcookieのname / valueに、何の意味を持たせるかはapplicationが決める。
session identifier。
表示言語。
同意の選択。
cartや一時的な状態の手掛かり。
同じCookieでも、serviceごとに役割は違う。
session cookieのvalue自体にaccount dataを全部入れるとは限らない。
server側のsession recordを探すためのopaque keyとして使う構成もある。
ユイ
browserの札と、serverのsession台帳を一枚に重ねないんですね
マコト
Cookie headerを受けた後に何をするかはapplication側の意味だ
イト
札を捨てることと、台帳の鍵を無効にすることは別なんだ
Picoはcookieを消さない。
browser box、request rail、server session ledgerを三つのinspection lightで分けた。
Cookieを消すと、browserからは送られなくなる
browserからcookie recordを削除すれば、以後そのrecordはrequestのCookie headerへ入らない。
serverがMax-Age=0などでcookieをexpireさせる場合もある。
その結果、serviceがsessionを見つけられずloginを求めることはある。
preference cookieなら、languageやthemeがdefaultへ戻る場合がある。
consent stateやcart stateがcookieに依存していれば、表示や中身が変わる場合もある。
だから削除前に、cookieのscopeとserviceの用途を確認する。
name application meaning
Domain receiving hosts
Path matching request paths
Expires / Max-Age lifetime
Secure secure-channel scope
HttpOnly non-HTTP API access limitattributeは役割が違う。
SecureやHttpOnlyが付いたからsession revocationまで自動で行われるわけではない。
よくある誤解：Cookieを消せばserver sessionも必ず消える
local cookie削除は、browserにあるrecordを消す操作だ。
server-side sessionをactiveからrevokedへ変えるかは、別のapplication operationになる。
official logoutがcurrent sessionをserver側でrevokeし、同時にbrowser cookieをexpireさせるserviceもある。
client cookieだけを消す構成もあり得る。
すべてのlogoutが同じ実装とは限らない。
今回のclosed fixtureでは、official logoutが二つを行う。
server session active -> revoked
browser cookie present -> expiredaccount、profile、server draftを削除するoperationは別だ。
Cookie削除を退会やaccount deletionの代わりにしない。
反対に、accountを消さなければshared browserからsign outできないとも考えない。
残り14秒の三択
次の利用者へbrowserを渡すまで、残り十四秒。
upload draft二件をserverへ保つ。
他siteのcookie七件へ触れない。
current upload sessionをserver側でrevokeする。
old sessionの再利用が拒否されることをtest fixtureで確認する。
logoutが失敗したらaccount deletionへ進まず、browserを渡さず管理者へ止める。
イトはcookie boxとsession ledgerの間に、三枚のroute cardを置いた。
イト
A。accountとdraftを全部消し、loginできる場所そのものをなくす
イト
B。browser全体のCookieを消し、server sessionは期限切れまで待つ
イト
C。uploadのofficial logoutでcurrent sessionをrevokeし、exact siteのcookieとsigned-outを確認する
Aは、shared browserからsign outする目的より大きな破壊だ。
Bは、他siteを巻き込みながらcurrent server sessionのstateを確認しない。
Cなら、browser recordとserver sessionを両側で確かめ、account / draftを別stateとして保てる。
イトがaccount shredderを閉じ、current-session gateを開いた
イトは左手で、account / draft shredderのred lidを閉じた。
all-site cookie vacuumにもlockを掛ける。
右手で、upload current-sessionだけのofficial logout gateを開いた。
イトはupload serviceのofficial logoutを一度だけ送った。
fixture serverはcurrent sessionをactive ledgerからrevoked drawerへ移した。
responseは同じupload cookieへexpiryを返した。
browserは受付札をcookie boxから外した。
Picoはbrowser cookieとserver sessionの境界を照らす。
logout button、ledger、cookie、drawerへ触れない。
signed-outになり、draftは二件残った
イトは同じupload URLを開き直した。
login entranceが表示された。
official logout accepted 1
server current session active 0
server current session revoked 1
browser upload cookie 0
next request login required 1
account exists 1
server drafts 2
other-site cookies retained 7fixtureのold session identifierを、isolated replay testerへ一度だけ入れた。
serverは受け付けなかった。
old session replay accepted 0イトはaccount ledgerとdraft二件を見た。
どちらも消えていない。
shared browserからのsign outと、account data deletionを分けた結果だった。
ただしlogout直前の未送信local form、client-only cart、preferenceなどはservice設計によって失われ得る。
削除前に必要な内容を保存し、recovery methodを確認する。
shared browserでの確認順
まず、何を終わらせたいか決める。
current login sessionか。
このbrowserに残るsite preferenceか。
account自体か。
目的がsign outなら、最初にserviceのofficial logoutを使う。
次にsigned-out pageと、protected pageへ戻れないことを確認する。
必要ならbrowser settingsでexact site / hostのcookie stateを確認する。
操作名と削除範囲はbrowserごとに違うため、選択中のsite / period / data categoryを読む。
passwordやrecovery methodが不明なら、先に消さない。
session theftが疑われる場合は、local cookie削除だけで終わらせず、serviceが用意するall-session logout、credential change、security page、supportへ進む。
どのoperationがserver sessionsをrevokeするかは、serviceの案内で確認する。
logout requestが失敗、signed-inのまま、old sessionが使えるなら、browserをshared stateで渡さず止める。
一枚の受付札が、二列のlampになった
logout receiptが、lab奥のstate encoderへ流れた。
cookie present 0
session active 0
account exists 1
draft count 2最初の三stateは、dark / lightのlampへ変わった。
draft countの2は、一つのlampに入らない。
encoderは複数のswitchを並べた。
イトはaccount exists 1のlampだけを残し、他を一個のswitchへ重ねようとした。
「0か1なら、一つのswitchで全部を言える？」
一つのstateと、複数のvalueを表すbit sequenceは同じではない。
イトはswitch mergerを閉じ、lampを順番どおりに戻した。
次回、ピコルート第95話。
イトは、一つの0と1だけで下書き二件まで表せる？｜二進数の入口