You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
chore(flags): Phase 2 — accept PSAK on the Django flag surfaces #66176
Accept PSAK on the Django surfaces that authenticate with the legacy team secret token today. Keep TeamSecretTokenAuthentication in place for back-compat throughout.
Tasks
remote_config: add ProjectSecretAPIKeyAuthentication and psak_allowed_actions = ["remote_config"], keep TeamSecretTokenAuthentication, and confirm scope enforcement and team binding.
Conversations external API: add PSAK support alongside (or replacing) the direct Q(secret_api_token=…) lookup. This product chose the team secret token deliberately because api_token is public, so loop in its owners and confirm PSAK semantics fit.
Resolve the header-only vs body-token difference. Legacy auth accepts the token in the request body; PSAK is header-only. Audit whether anything sends the secret token in the body for these endpoints; if so it stays on the legacy path until it moves to the header.
Acceptance
A feature_flag:read PSAK authenticates remote_config (and any other migrated surface) with correct scope and team enforcement.
Existing team secret tokens keep working unchanged.
Body token audit is done. I checked all our server SDKs (python, node, php, go, ruby, rust, dotnet and java) and every single one sends the key as an Authorization header, none of them ever puts it in the request body. On top of that, the counter we've had in production since March (api_auth_secret_api_key_body) has never fired once, in US or EU. Also all the endpoints that accept this token are GET or read the header only, so there is nowhere a body token could even arrive.
Conversations external API: resolved. Instead of adding PSAK support "alongside or replacing" the token lookup, the route now dual-accepts: GET takes a project secret API key with the new support_ticket:read scope (#107942, merged with the Conversations team's OK), and the legacy token keeps working until the column drop. Same pattern customer analytics used in #97599. With this, every surface in this phase accepts PSAKs.
All three items done — closing Phase 2. Remaining phases tracked in #66178 (customer migration via the hashed-token backfill) and #66179 (deprecate and drop).
Activity
feat(flags): throttle remote_config PSAK usage per key and per team
patricio-posthog commentedon Jul 6, 2026
Body token audit is done. I checked all our server SDKs (python, node, php, go, ruby, rust, dotnet and java) and every single one sends the key as an Authorization header, none of them ever puts it in the request body. On top of that, the counter we've had in production since March (
api_auth_secret_api_key_body) has never fired once, in US or EU. Also all the endpoints that accept this token are GET or read the header only, so there is nowhere a body token could even arrive.patricio-posthog commentedon Sep 30, 2026
Conversations external API: resolved. Instead of adding PSAK support "alongside or replacing" the token lookup, the route now dual-accepts: GET takes a project secret API key with the new
support_ticket:readscope (#107942, merged with the Conversations team's OK), and the legacy token keeps working until the column drop. Same pattern customer analytics used in #97599. With this, every surface in this phase accepts PSAKs.patricio-posthog commentedon Sep 30, 2026
All three items done — closing Phase 2. Remaining phases tracked in #66178 (customer migration via the hashed-token backfill) and #66179 (deprecate and drop).