データ認証
セッション
ログイン状態はクッキーで保持します。サーバー側でセッションを参照するため、セッションを破棄するとすぐに反映されます。
ログインすると、次のクッキーが作成されます。
__Host-runlot_auth=v1.<ランダムな 32 バイト>; Secure; HttpOnly; SameSite=Lax; Path=/デフォルトのセッション期間は 30 日です。
runlot auth set session-days 7署名トークンではなくサーバーセッションを使います
クッキーに入っているのは署名付きトークンではなく、ランダムな値です。サーバーはその値のハッシュでセッションテーブルを参照します。参照が 1 回増えますが、セッションを破棄すればすぐにログイン状態を解除できます。署名トークンだけを使う場合は、トークンが失効するまで待つ必要があります。
await env.auth.sessions.revokeAll(userId); // このユーザーのすべてのセッションをすぐに破棄しますブラウザ以外の環境で使う
モバイルアプリやサーバーからは、次のヘッダーでセッションの値を送れます。
Authorization: Bearer v1.<同じ値>Authorization ヘッダーはクッキーより優先されます。このヘッダーを使うリクエストには CSRF チェックを適用しません。
ログアウト
return new Response(null, {
status: 302,
headers: { location: "/", ...(await env.auth.signOut(request)) },
});ブラウザのフォームからは POST /__runlot/auth/sign-out にリクエストを送ってもかまいません。どちらの方法でも、セッションテーブルの行を削除してクッキーを空にします。
データベースでセッションを確認する
select user_id, created_at, last_seen_at, expires_at
from runlot_auth.sessions
order by last_seen_at desc
limit 20;トークンはハッシュ値としてのみ保存されます。last_seen_at はリクエストごとではなく 1 日に 1 回更新します。読み取りリクエストのたびに書き込みが発生しないようにするためです。
期限切れのセッションは、ログイン確認 100 回につき 1 回まとめて整理します。
セッションクッキーに必要な環境
クッキー名が __Host- で始まるため、HTTPS でのみ送信されます。デプロイされたアドレスは常に HTTPS を使います。ローカルの HTTP アドレスで開いた画面では、セッションは保持されません。