feat: add secret_key config, deprecate personal_api_key#211
feat: add secret_key config, deprecate personal_api_key#211turnipdabeets wants to merge 2 commits into
Conversation
Add `secret_key` as the canonical credential for local flag evaluation and remote config (accepts a Personal API Key or a Project Secret API Key). `personal_api_key` remains a deprecated alias; `secret_key` wins when both are set. Non-breaking.
posthog-ruby Compliance ReportDate: 2026-07-02 16:15:05 UTC ✅ All Tests Passed!46/46 tests passed Capture Tests✅ 29/29 tests passed View Details
Feature_Flags Tests✅ 17/17 tests passed View Details
|
|
|
Reviews (2): Last reviewed commit: "Regenerate API snapshot, rename poller s..." | Re-trigger Greptile |
Problem
The credential used for local feature flag evaluation and remote config accepts either a Personal API Key (
phx_...) or a Project Secret API Key (phs_...). Today the only option name is:personal_api_key, which is confusing — users with a Project Secret API Key reasonably assume the option won't accept it.Change
:secret_keyoption toPostHog::Client.new(and the Railsconfig.secret_key=setter). It accepts either a Personal API Key (phx_...) or a Project Secret API Key (phs_...).:personal_api_keyworking as a deprecated alias. When only the alias is used, a deprecation warning points users at:secret_key.:secret_keywins.@secret_key, with@personal_api_keykept as a mirror so existing reads (the flags poller auth headers) keep working unchanged.@optiondocs, the flag-definition-cache doc example, and the Rails/generator config examples to demonstrate the canonical option.Non-breaking — existing
:personal_api_keycallers keep working.Specs added in
spec/posthog/client_spec.rbprove::secret_keysets the credential,:personal_api_keystill works and warns, and:secret_keywins when both are provided. Full suite (580 examples) passes; RuboCop clean.Context