fix(flags): Deterministic project selection for the remote_config endpoint

[haacked]

Adds a means for deterministic project selection when calling the remote_config endpoint.

Problem

See #35303 for more context, but in-short, remote_config endpoint is accessed with a GET request to /api/projects/@current/feature_flags/unencrypted-remote-config-setting/remote_config/

When using a personal access token for authentication, this causes the request to route to whichever project the user the token belongs to last visited.

Fixes #35303

Changes

1. Update remote_config to support POST requests.
2. When a POST request occurs, look in the request body for project_api_key to override the @current token.
3. Update ProjectSecretAPIKeyAuthentication to validate that the token team and resolved team match.

The changes should be backwards compatible. So if somebody had a need for the project switching ability of the @current URL, they still get that behavior when making a GET request.

I'll update the SDKs to make a POST request and pass the project api token in the request body.

How did you test this code?

Manually.
Unit Tests.

• GET personal_api_key, no request body. Expect: returns last visited project
• GET personal_api_key, api_key in request body. Expect: returns last visited project
• POST personal_api_key, no request body. Expect: returns last visited project
• POST personal_api_key, api_key in request body. Expect: returns project with api_key
• POST personal_api_key, api_key for different project in request body. Expect: Auth error
• GET secret_api_key, no request body. Expect: returns project associated with the key
• GET secret_api_key, api_key in request body. Expect: returns project associated with the key
• POST secret_api_key, no request body. Expect: returns project associated with the key
• POST secret_api_key, api_key in request body. Expect: returns project associated with the key
• POST secret_api_key, api_key for a different project in request body. Expect: Auth error

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

Client SDKs that need to be updated

• posthog-python - fix(flags): Pass project API key in remote_config requests posthog-python#303
• posthog-dotnet
• posthog-go
• posthog-elixir
• posthog-node
• posthog-php
• posthog-ruby
• posthog-rust

[Copilot]

Pull Request Overview

This PR implements deterministic project selection for the remote_config endpoint by adding support for POST requests and project API token validation. This fixes an issue where personal access tokens would route to whichever project the user last visited.

• Enhanced ProjectSecretAPIKeyAuthentication to validate project API tokens in request bodies
• Updated the feature flag endpoint to accept both GET and POST methods
• Modified project routing logic to handle request body tokens for POST/PUT/PATCH methods

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
posthog/auth.py	Added security validation to ensure project API tokens in request body match authenticated projects
posthog/api/test/test_authentication.py	Added comprehensive test coverage for the new authentication validation scenarios
posthog/api/routing.py	Updated team resolution logic to check request body for tokens on POST/PUT/PATCH methods
posthog/api/feature_flag.py	Extended remote_config endpoint to support POST requests alongside existing GET support

Comments suppressed due to low confidence (1)

posthog/api/test/test_authentication.py:1082

• The test is catching a generic Exception instead of the specific AuthenticationFailed exception that should be raised. This makes the test less precise and could pass if a different exception is thrown.

        with self.assertRaises(Exception) as context:

[greptile-apps]

Greptile Summary

This PR fixes a critical issue with the remote_config endpoint where personal API keys would route to whichever project the user last visited rather than the intended project. The solution introduces deterministic project selection by enabling POST requests with a project API token in the request body.

The key changes include:

1. Enhanced endpoint support: The remote_config endpoint in posthog/api/feature_flag.py now accepts both GET and POST methods, with POST allowing project specification via request body

2. Request routing updates: Modified _get_team_from_request() in posthog/api/routing.py to conditionally pass request data to get_token() for POST/PUT/PATCH methods, enabling project token extraction from request bodies

3. Security validation: Added authentication checks in ProjectSecretAPIKeyAuthentication class in posthog/auth.py to ensure any project API key provided in the request body matches the team associated with the secret API key used for authentication

4. Comprehensive testing: Added unit tests in posthog/api/test/test_authentication.py covering scenarios with matching keys, mismatched keys, and no keys in the request body

The implementation maintains full backward compatibility - existing GET requests continue to work with the @current project behavior, while new POST requests provide deterministic routing. This fits into PostHog's broader authentication and project management system by extending the existing token validation mechanisms to handle multi-project scenarios more reliably.

Confidence score: 4/5

• This PR is safe to merge with minimal risk as it maintains backward compatibility while fixing a legitimate routing issue
• Score reflects solid implementation with comprehensive testing and proper security validation, though the complexity of authentication logic requires careful attention
• Pay close attention to the authentication validation logic in posthog/auth.py to ensure the security checks work correctly across different authentication scenarios

_{4 files reviewed, 1 comment}

_{Edit Code Review Bot Settings | Greptile}

[haacked]

Hmm, test failures seem unrelated to the changes in this PR.

[haacked]

@benjackwhite Added you because this touches the project secret api token logic.

[haacked]

Changing get_token broke too many tests. Those test failures were in fact related to the changes I had made. I refactored this PR to be more targeted and not to mess with get_token.