セッションの保存と継続

投票から証明の検証までは、複数の画面を移動します。再読み込みで投票時の情報を失うことも、別タブで作ったセッションの結果を今の票と取り違えることも避ける必要があります。

ブラウザとサーバーに残すもの

ブラウザとサーバーの対応は、URL の sessionId と X-Session-Capability で確認します。集計・検証のデータでは finalizationId も照合します。

保存されたブラウザの値も無条件には信用しません。admitStoredSessionData() が識別情報、期限、進行段階、投票の秘密情報とレシートの組、集計結果を検査します。未知のフィールドや必要な組の欠落、段階と集計状態の矛盾があれば拒否します。

読み取りで不正な値が見つかった場合は、starkBallotSession、stark-ballot-knowledge、starkBallotSessionLock を消去します。書き込みであれば保存せず Invalid browser session state として失敗します。情報の一部を削って、整合しているように見せる修復は行いません。

投票から検証へ進む条件

ブラウザの進行段階は次の三つです。集計の pending や succeeded とは別に、画面を継続するために保存します。

Result から Verify へ進むときは、検証を要求した時刻 verificationRequestedAt を保存し、必要なら STARK 検証を先に開始します。Verify は次の条件で継続を判断します。

1. 正しい finalizeResult と verificationRequestedAt が揃っていれば継続できる。
2. それらが揃わなくても、サーバーの STARK 検証が not_run 以外なら進める。
3. どちらも満たさなければ、検証を始める根拠がないため停止する。

ここで受け入れる finalizeResult は、現行のデータ形式と整合条件を満たす集計結果です。verifying 段階では必須であり、要求時刻は非負の整数だけを許します。

投票の応答を受け取れなかった場合

送信前に選択・乱数・コミットメントの組を保存します。応答が不明な間はその組を固定し、 再試行や再読み込みで新しい乱数を生成しません。同じ内容の再送でサーバーに残る票のレシートを回収し、 不足するボット票の保存を完了させます。Turnstile が必要な環境では、再試行用のトークンを改めて取得します。

サーバーは再送で票 ID や投票時刻を更新しません。異なる内容の再投票と、集計開始後の票の追記は拒否します。 DynamoDB の競合再試行でも保存時の票数上限を検査するため、同時にボット補完が走っても63票を超えて追記しません。

再読み込みと別タブ

同じオリジンのタブは localStorage を共有します。片方で新しいセッションを作ると、もう片方の画面に残る情報と保存値が食い違う可能性があります。タブごとのロックを比較し、古いセッションを見ている aggregate、result、verify、bot progress の画面は進行を止めます。

同じセッションへの二重操作はサーバーでも拒否します。投票済みなら ALREADY_VOTED、集計完了後の再集計なら SESSION_ALREADY_FINALIZED を返します。

クライアントの期限は、保存や活動時刻の更新でその段階に応じて延長します。Verify では 60 秒ごとにローカルの活動時刻を更新します。これはブラウザ内の更新であり、サーバーの期限を延長する heartbeat API ではありません。期限切れを検出すると clearSession() で保存状態を消去します。

サーバーでは状態ごとに記録する

サーバーは、セッションのすべてを一つの可変オブジェクトとして保存するのではなく、意味の異なる記録を分けます。

読み出す際は必要な記録を SessionReadModel にまとめられますが、その合成結果を保存用の正本にはしません。必要な記録の欠落や内部の集計 ID の不一致を見つけた場合は、値を作り足さずエラーとして扱います。

集計の状態は pending、running、succeeded、failed、timeout です。現在の状態と操作から、更新するか、同じ操作の再送か、古い操作として拒否するかを application 層で決めます。Mock・File・DynamoDB の各保存実装は、その判断をロックや条件付きトランザクションで反映します。

検証画面からの観測を保存する

検証シーケンスが完了すると、ブラウザは Cast チェックの観測を送ります。サーバーは最初の観測を finalizationId、内容の fingerprint、observedAt で記録し、同じ集計と同じ内容の再送を受け入れます。集計や内容が競合する送信は拒否します。

この記録は、利用者にどの状態が見えたかを調べ、観測イベントの重複を防ぐためのものです。送信や保存に失敗しても、証明、集計結果、検証結果、画面の判定は変更しません。

保存期間とセッション数の制限

クライアントの期限と、サーバーにデータが残る期間は別です。

DynamoDB では、作成時に SESSION_LIVE_TTL_SECONDS を使います。その後の投票や活動では、識別情報、投票状態、各票の期限を「現在の期限」と「現在時刻に live TTL を加えた値」の大きい方に揃え、条件付きトランザクションで更新します。競合や欠落で一部だけを更新することはありません。

集計状態の更新が適用されると、セッションの記録を VERIFICATION_ARTIFACT_TTL_SECONDS の期限へ移し、後の活動で短縮しません。検証結果、観測、保存・配送情報にもこの証拠用の TTL を使います。

一方、セッション作成上限を判定する際は、最終活動から 5 分以内かを調べます。この活動判定は DynamoDB の物理的な削除時刻とは別です。作成数が MAX_SESSIONS に達すると、POST /api/sessions は SESSION_LIMIT_EXCEEDED を返します。