Vai al contenuto

Smoke public-content protetto

Quando usarlo

Il percorso API di ogni release verifica sempre che /topics, /knowledge-assets e /issues restino protetti da Cloudflare Access. Quando la coppia credenziale riutilizzabile è configurata nell'Environment GitHub corrispondente, lo stesso step esegue anche lo smoke REST autenticato e read-only.

Questo canale riusa il Service Token del Public Site dello stesso ambiente. Non crea una seconda identità, policy, application o authority applicativa e non riconcilia Access durante la release.

Wiring protetto

Gli Environment GitHub development e production possono custodire due secret omonimi ma con valori distinti per ambiente:

  • PUBLIC_CONTENT_ACCESS_CLIENT_ID;
  • PUBLIC_CONTENT_ACCESS_CLIENT_SECRET.

I valori sono la stessa coppia già usata dal Public Site server-side nell'ambiente corrispondente. La loro configurazione o rotazione è configurazione diretta dell'operatore e non appartiene al checkout. Non registrare mai valori, client ID raw, assertion, cookie o payload nelle Issue, nelle PR, nei log o nel summary.

Il workflow espone i secret soltanto allo step smoke_api. Migrazione, upload, attivazione, MCP ed evidence non li ricevono. Il processo invia la coppia solo agli header CF-Access-Client-Id e CF-Access-Client-Secret verso l'origine HTTPS repository-owned dello stesso ambiente; un override dell'origine non può ricevere credenziali.

Sequenza

  1. Senza credenziali, richiedere le tre collection bounded e accettare soltanto una delle due shape 401 Access approvate e senza redirect:
  2. Managed OAuth con challenge Bearer e un solo resource_metadata same-origin esatto;
  3. Service Auth senza challenge, con CF-Access-Domain uguale all'host atteso, CF-Access-Aud e CF-Version presenti e Server: cloudflare. Non confrontare il contenuto dell'audience e non dipendere da CF-Ray, request ID o altri identificatori provider volatili.
  4. Se entrambi i secret sono assenti e il percorso non richiede evidenza autenticata, registrare not-run.
  5. Se la coppia è parziale, richiesta ma assente o invalida, fallire chiuso.
  6. Se configurata, leggere con GET e bound massimo 100 Topic, Knowledge Asset e Issue pubblici senza stampare i valori campionati.
  7. Derivare da un Topic pubblico safe query che provano:
  8. scalar AND;
  9. repeated-array AND;
  10. scalar .any;
  11. array .any;
  12. AND tra gruppi;
  13. base field più lo stesso field.any uguale a HTTP 400.
  14. Richiedere con la stessa identità /admin/auth/me e accettare soltanto la negazione Access.
  15. Presentare la stessa coppia alla collection /topics dell'altro ambiente e richiedere una delle stesse shape protette, vincolata all'host opposto.
  16. Registrare soltanto success, not-run o failure nel summary.

Lo smoke remoto non invia mai POST, PUT, PATCH o DELETE. L'assenza di route mutative sotto le famiglie content resta un contratto repository-owned coperto dai test, così una regressione futura non può essere scoperta eseguendo accidentalmente una mutation live.

Uso locale autorizzato

I comandi canonici restano:

npm run smoke:api:development
npm run smoke:api:production

Senza coppia configurata producono il protected-front-door pass e l'authenticated not-run. Per un contesto che richiede obbligatoriamente il canale autenticato:

npm run smoke:api:development -- --require-public-content-auth

Fornire i secret soltanto tramite il processo autorizzato; non salvarli in file .env, shell history o script.

Condizioni di stop

Fermarsi su coppia parziale, 401 generico o applicativo, evidenza Access mancante o per l'host errato, redirect, origine non canonica, risposta non JSON, shape privata, collection safe vuota, semantica filtro divergente, Admin ammesso, credenziale accettata dall'altro ambiente o outcome ambiguo. Non creare token, non ampliare policy e non usare Bypass, Everyone o Any Access Service Token come correzione.