CDN bot protection blocks QA test runs

未关闭
#151 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 7 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
aws, github-actions, playwright

调研方向

The repo-side work is in .github/workflows/qa.yml, where the bypass secret and header name would be passed only to the Playwright test steps, plus the Playwright config, where traces must be disabled whenever the header is set and the header must be scoped to the site's own host. The AWS WAF rule and the secret setup belong to infra and repo admins and cannot be done from code. Done means a manual QA run against staging and prod returns no 403s, and traces stay off when the header is present.

由索引模型根据 Issue 内容生成。

描述

What's wrong: strapi.io (prod and staging) is behind CloudFront + AWS WAF bot protection. After a burst of automated requests, it answers Playwright test traffic with HTTP 403 "Request blocked … Generated by cloudfront"; WebKit gets blocked almost immediately. Test runs then fail on blocked pages instead of on real issues (the tests now report "Unexpected HTTP status … 403"). CI and scheduled runs (.github/workflows/qa.yml) will hit the same.

Ask (infra / CDN owners): an AWS WAF rule that lets requests carrying a secret header through:

  • match header x-qa-bypass (name up to you) against a secret value
  • action Allow, placed before the bot-control and rate-based rules (or exclude matching requests from them via a scope-down statement)
  • on both CloudFront distributions, staging and prod
  • share the value with QA through a secure channel (not chat or Jira); rotate it if it leaks

An IP allowlist doesn't work well: GitHub-hosted runners don't have fixed IPs.

Ask (repo admins): GitHub → Settings → Secrets and variables → Actions:

  • secret CDN_BYPASS_HEADER_VALUE
  • variable CDN_BYPASS_HEADER_NAME, only if the header isn't x-qa-bypass
  • optionally, put the secret in a GitHub Environment restricted to staging and main

QA side (how the secret stays safe):

  • the header is only sent to our own host, never to third-party scripts (Cookiebot, Google, HubSpot, …)
  • only the test steps in qa.yml get it; the workflow is manual-only, and runs from forks never receive secrets
  • Playwright traces are disabled while it's set (they record headers and are uploaded as artifacts in our public repo); Lighthouse runs without it

Done when: a full QA run against prod and staging with the header gets no 403s.

主要语言
TypeScript
星标
6
派生
5
平均合并
5 天 6 小时
30 天内合并 PR
7

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

strapi/website 的其他 Issue

查看 strapi/website 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。