如何在Github Actions的Lighthouse CI Action中传入凭证，实现对认证后部署环境的审计？

你完全不需要局限于staticDistDir方式——针对受认证保护的PR部署预览环境，有几个直接可行的方案，尤其是基础认证的场景配置起来很简单，下面一步步给你说明：

1. 直接处理基础认证（Basic Auth） #

treosh/lighthouse-ci-action支持通过extraHeaders参数传递自定义HTTP头，刚好可以用来携带基础认证的授权信息。具体操作如下：

步骤1：生成基础认证Token #

把你的基础认证用户名和密码用username:password的格式拼接，然后做Base64编码（可以用终端命令echo -n "username:password" | base64生成）。

步骤2：存储敏感信息到GitHub Secrets #

把生成的Base64字符串存到仓库的GitHub Secrets里，比如命名为LIGHTHOUSE_BASIC_AUTH_TOKEN——绝对不要硬编码到工作流文件里。

步骤3：修改工作流配置 #

更新你的Lighthouse CI步骤，添加extraHeaders参数：

- name: Audit URLs using Lighthouse
  uses: treosh/lighthouse-ci-action@v7
  id: lighthouse_audit
  with:
    urls: |
      # 这里替换成你的PR部署预览URL，动态的话可以用上下文变量，比如${{ steps.deploy.outputs.preview_url }}
      https://your-protected-pr-preview.example.com/
    budgetPath: ./.github/workflows/budget.json
    uploadArtifacts: true
    temporaryPublicStorage: true
    extraHeaders: |
      {"Authorization": "Basic ${{ secrets.LIGHTHOUSE_BASIC_AUTH_TOKEN }}"}

这样Lighthouse请求你的受保护页面时，会自动带上基础认证头，就能正常访问并执行审计了。

2. 处理更复杂的认证（比如会话Cookie） #

如果你的部署环境用的不是基础认证，而是需要登录后获取会话Cookie才能访问，可以在工作流里先加一步登录操作，拿到认证Cookie后再传递给Lighthouse。

举个用curl登录获取Cookie的例子：

# 先执行登录，获取认证Cookie
- name: Fetch auth cookie
  id: get_auth_cookie
  run: |
    # 替换成你的登录接口和参数
    COOKIE=$(curl -s -c - -X POST https://your-auth-domain.example.com/login \
      -d "username=${{ secrets.AUTH_USERNAME }}" \
      -d "password=${{ secrets.AUTH_PASSWORD }}" | grep -oP 'session_id=\K[^;]+')
    echo "COOKIE_VALUE=$COOKIE" >> $GITHUB_OUTPUT

# 然后用拿到的Cookie执行Lighthouse审计
- name: Audit URLs using Lighthouse
  uses: treosh/lighthouse-ci-action@v7
  id: lighthouse_audit
  with:
    urls: |
      https://your-protected-pr-preview.example.com/
    budgetPath: ./.github/workflows/budget.json
    uploadArtifacts: true
    temporaryPublicStorage: true
    extraHeaders: |
      {"Cookie": "session_id=${{ steps.get_auth_cookie.outputs.COOKIE_VALUE }}"}

注意：不同的认证系统登录逻辑可能不同，需要根据实际情况调整curl的请求体、请求头或者Cookie的键名。

3. 适配PR工作流的动态URL #

如果你的PR部署预览URL是动态生成的（每个PR有独立的域名/路径），可以直接用GitHub Actions的上下文变量来获取。比如很多部署工具（像Vercel、Netlify）会在部署步骤输出预览URL，你可以通过${{ steps.deployment-step-id.outputs.preview_url }}这样的方式引用，不用硬编码固定URL。

总的来说，这些方案都不需要依赖staticDistDir，完全可以直接对受认证保护的PR部署环境执行Lighthouse审计，完美匹配你团队的需求。

内容的提问来源于stack exchange，提问作者Berimbolinho