verify-login-logout

画面にサインイン済みと表示されても、サインイン済みとは限りません

ログインフォームの送信後にダッシュボードが表示されても、ページが変わったことしか証明できません。サーバーが認証情報を受け付けたことや、サインアウトでセッションが終了すること、セッションの期限が切れたユーザーに空白の画面や401のループではなくサインインページが表示されることは証明できません。

Reticle なら、実行中のアプリでこの3つを確認できます。未インストールの場合は、RETICLE_INSTALL_SOURCE=npx_skill npx @reticlehq/server@latest init を実行し、install-and-verify スキルを使ってください。

始める前に

• プロジェクトのテストアカウントを使ってください。 認証情報はシードデータ、フィクスチャ、.env.example から取得するか、ユーザーに尋ねてください。実在する人のパスワードを入力しないでください。
• セッションが監視できることを確認してください： reticle_session({ action: "list" })。非表示またはスロットリングされたタブでは、クリックを受け付けても何も表示されないことがあります。正常でなければ、実行結果を合格ではなくブロックとして報告してください。
• ステップ3には、Reticle が所有するブラウザーが必要です。 期限切れセッションを強制するには reticle_network_mock を使います。これはリースされたタブ（reticle_run({ tool: "reticle_lease", args: { action: "acquire", url } })）または操作中のタブでは動作しますが、常時有効なSDKでは動作しません。そうしたタブがない場合は、ステップ1と2を行い、ステップ3は不明として報告してください。

1. サインインし、遷移先を明示する

reticle_look({ action: "page", sessionId, mode: "interactive" }) でフォームの参照を取得し、reticle_act でフィールドに入力します。その後、送信前に、クリックした結果どうなるべきかを明示してください。

reticle_act_and_wait({ sessionId, ref: "<sign-in button>", action: "click", until: { kind: "allOf", predicates: [
  { kind: "net", urlContains: "/api/login", ok: true },
  { kind: "route", pathname: "/dashboard" },
  { kind: "element", query: { role: "button", name: "Account" } },
]}})

3つすべてを確認してください。どれか1つだけでは誤った判断につながる可能性があるためです。サーバーの応答前にクライアント側でルートが変わることもあり、ユーザーメニューが古いキャッシュから表示されることもあります。実際のアプリのオリジン、エンドポイント、遷移先ルート、サインイン済みの目印を一貫して使ってください。ここにあるものは例です。

reticle_run({ tool: "reticle_storage", sessionId, args: {} }) で、アプリが保存した内容を確認できます。機密性の高いキーは伏せられ、httpOnly Cookie は設計上ページから見えません。そのため、これはセッションがどこに保存されているかを示す証拠であり、判定そのものではありません。

2. サインアウトしてから、戻れるか試す

reticle_act_and_wait({ sessionId, ref: "<sign-out control>", action: "click", until: { kind: "allOf", predicates: [
  { kind: "route", contains: "/login" },
  { kind: "element", query: { role: "button", name: "Account" }, absent: true },
]}})

サインインページに戻ることは、UIが移動した証拠です。セッションが終了した証拠ではありません。アプリの実際のオリジンとルートで、保護されたページに直接移動し、アクセスが拒否されることを証明してください。

reticle_navigate({ sessionId, url: "<the app's origin>/dashboard" })
reticle_assert({ sessionId, predicate: { kind: "allOf", predicates: [
  { kind: "route", contains: "/login" },
  { kind: "text", contains: "Sign in" },
  { kind: "net", urlContains: "/api/me", status: 401 },
]}})

net 条件が、サーバーがセッションを終了したことを証明します。クライアント側のガードは、クリアされたフラグを見て /login にリダイレクトできますが、サーバーは古いセッションを引き続き有効とみなしているかもしれません。その場合、ルートとテキストの検証には合格してしまいます。サインイン中のユーザーを確認するためにページが行うリクエストは、今度は拒否される必要があります。ページがそのようなリクエストを行わない場合は、そのことを伝え、サーバー側の検証結果は不明として報告してください。

サインアウト後も保護されたページが表示されることは、このスキルで得られる最も重要な検出結果です。他のすべてに合格していても、必ず報告してください。

3. セッションを期限切れにし、アプリが再度確認することを証明する

再度サインインします（ステップ1）。次に、セッション確認にアプリが使う呼び出しを失敗させ、サーバーがセッションを期限切れとして扱うようにします。

reticle_run({ tool: "reticle_network_mock", sessionId, args: {
  mocks: [{ urlContains: "/api/me", status: 401 }],
}})

保護されたページを再読み込みし、何が起きるべきかを明示してください。

reticle_navigate({ sessionId, url: "<the app's origin>/dashboard" })
reticle_assert({ sessionId, timeout_ms: 5000, predicate: { kind: "allOf", predicates: [
  { kind: "net", urlContains: "/api/me", status: 401 },
  { kind: "route", contains: "/login" },
  { kind: "console", level: "error", absent: true },
]}})

net 条件は、モックした 401 にアプリが反応したことを証明します。アプリがモックしたエンドポイントを呼び出していない場合、それでもリダイレクトが起きたとしても偶然であり、期限切れへの対応を示すものではありません。アプリが実際に呼び出すリクエストをモックするまでは、判定は不明です。コンソール条件も重要です。未捕捉のエラーを投げて空白のページを表示することで期限切れを「処理」するアプリは、適切に処理できていません。完了したら { clear: true } でモックを解除してください。

誠実な報告

合格となるのは verified: "yes" の場合のみです。ステップ3は代替手段です。Reticle は httpOnly Cookie を削除したり、ストレージを編集したりできないため、期限切れを強制するにはモックした 401 を使います。どのエンドポイントをモックしたかを明記してください。引き継ぐ前にすべてのモックを解除してサインアウトし、確認したパスワード、トークン、Cookie の値は決して報告しないでください。

---

機能のリファレンス：curl https://docs.reticle.sh/capabilities.md。その他すべて：curl https://docs.reticle.sh/llms.txt。