playwright-auth-wrapper

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Playwright Auth Wrapper

Playwright Auth Wrapper

Enable one manual login to serve multiple parallel automation tasks. Every Launch reads the same saved authentication state into a fresh, isolated Browser Context and never writes that shared state.
Select the appropriate subflow while preserving strict state ownership:
  • Setup creates configuration and installs the pinned private Playwright runtime.
  • Login is the only subflow allowed to write
    storage-state.json
    .
  • Launch is the default and never writes shared authentication state.
实现一次手动登录即可服务于多个并行自动化任务。每次Launch都会将同一个已保存的认证状态读取到全新的独立Browser Context中,且绝不会写入该共享状态。
在严格保持状态所有权的前提下选择合适的子流程:
  • Setup 创建配置并安装固定版本的私有Playwright运行时。
  • Login 是唯一允许写入
    storage-state.json
    的子流程。
  • Launch 是默认子流程,绝不会写入共享认证状态。

Route the request

路由请求

  1. Run the read-only readiness check:
    bash
    node <skill-directory>/scripts/status_shared_auth.cjs
  2. If
    setupRequired
    is true, read references/setup.md and run only the required Setup stages automatically before any other subflow. Tell the user that first-time runtime installation may take a few minutes because it downloads and launch-tests Chromium.
  3. After automatic Setup:
    • Continue directly to Login only when the user's original request explicitly asked to log in, add a login, or refresh expired authentication.
    • Otherwise stop and ask whether they want to log in now. If no target URL is known, ask for it only after they say yes.
  4. If setup is ready, route explicit installation or context-option changes to references/setup.md.
  5. Route explicit login, re-login, expired-session, or shared-state update requests to references/login.md.
  6. Route every other browser-opening, screenshot, verification, or automation request to references/launch.md. Launch is the normal daily path.
If the intent is ambiguous but a target URL is available, choose Launch. A redirect to a login page is evidence to offer Login; it is not permission to write shared state automatically.
  1. 运行只读就绪检查:
    bash
    node <skill-directory>/scripts/status_shared_auth.cjs
  2. 如果
    setupRequired
    为true,请阅读references/setup.md并在执行任何其他子流程前自动运行所需的Setup阶段。告知用户首次运行时的运行时安装可能需要几分钟,因为需要下载并启动测试Chromium。
  3. 自动完成Setup后:
    • 仅当用户初始请求明确要求登录、添加登录信息或刷新过期认证时,直接进入Login流程。
    • 否则停止操作并询问用户是否现在要登录。若未知目标URL,仅在用户确认要登录后再询问该URL。
  4. 如果Setup已就绪,将明确的安装或上下文选项更改请求路由至references/setup.md
  5. 将明确的登录、重新登录、会话过期或共享状态更新请求路由至references/login.md
  6. 将所有其他打开浏览器、截图、验证或自动化操作请求路由至references/launch.md。Launch是日常操作的常规路径。
若意图不明确但已知目标URL,则选择Launch流程。重定向至登录页面可作为提供Login流程的依据,但不代表自动写入共享状态的权限。

Shared invariants

共享不变量

  • Use the OS user data directory by default; honor
    PLAYWRIGHT_SHARED_AUTH_DIR
    or an explicit
    --auth-dir
    consistently across all subflows.
  • Keep one private Playwright runtime and one shared state directory, but create a fresh Browser Context for each automation task.
  • Permit concurrent Launch readers. Serialize Login writers with the state lock.
  • Never commit, paste, or expose
    storage-state.json
    , cookies, tokens, confirmation markers, or authentication screenshots.
  • Preserve configured locale, timezone, and headers unless the user explicitly asks to change them.
  • Sanitize reported URLs by removing credentials, query parameters, and fragments.
  • On POSIX systems, keep the auth directory at
    0700
    and state/config/metadata/screenshots at
    0600
    .
  • Do not treat a timeout as successful login. Leave existing state unchanged and report that nothing was saved.
  • 默认使用操作系统用户数据目录;在所有子流程中统一遵循
    PLAYWRIGHT_SHARED_AUTH_DIR
    或显式指定的
    --auth-dir
  • 保留一个私有Playwright运行时和一个共享状态目录,但为每个自动化任务创建全新的Browser Context。
  • 允许并发的Launch读取操作。通过状态锁对Login写入操作进行序列化。
  • 绝不要提交、粘贴或暴露
    storage-state.json
    、Cookie、令牌、确认标记或认证截图。
  • 保留已配置的区域设置、时区和请求头,除非用户明确要求更改。
  • 通过移除凭证、查询参数和片段来清理上报的URL。
  • 在POSIX系统上,将认证目录权限设置为
    0700
    ,状态/配置/元数据/截图权限设置为
    0600
  • 不要将超时视为登录成功。保留现有状态不变并报告未保存任何内容。