-
Notifications
You must be signed in to change notification settings - Fork 2.2k
feat(feature-flags): add posthog-server user agent for server-side SDK detection #45652
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(feature-flags): add posthog-server user agent for server-side SDK detection #45652
Conversation
…K detection
This adds support for the `posthog-server/*` user agent pattern, allowing
client-side SDKs (like posthog-android, posthog-ios) running in server mode
to be properly detected as server-side runtime.
When a client SDK is used on the server (e.g., Android SDK in a backend
service), it can now send `posthog-server/{version}` as the user agent
to receive server-only feature flags.
Related: PostHog/posthog-android#382
Greptile found no issues!From now on, if a review finishes and we haven't found any issues, we will not post anything, but you can confirm that we reviewed your changes in the status check section. This feature can be toggled off in your Code Review Settings by deselecting "Create a status check for each PR". |
|
Oof @dustinbyrne, this feels a bit wrong. I feel like the SDK should be saying We used to get Of course, it's saying |
yeah posthog-server is very generic, agree, either just posthog-java or posthog-java-server |
…tion
PostHog's runtime detection uses User-Agent patterns to determine if
requests come from server-side or client-side SDKs. The pattern
"posthog-server/" is not recognized, so we use "posthog-java/server/"
instead until PostHog adds support for "posthog-server/" in their
detection patterns.
Changes:
- Make userAgent configurable in core PostHogConfig (via setter)
- Add getUserAgent() method for internal use
- Server module sets userAgent to "posthog-java/server/{version}"
See: PostHog/posthog#45652
…tion
PostHog's runtime detection uses User-Agent patterns to determine if
requests come from server-side or client-side SDKs. The pattern
"posthog-server/" is not recognized, so we use "posthog-java/server/"
instead until PostHog adds support for "posthog-java-server/" in their
detection patterns.
Changes:
- Add internal userAgent property to core PostHogConfig (@PostHogInternal)
- Add getUserAgent() method that returns userAgent or falls back to sdkName/sdkVersion
- Server module sets userAgent to "posthog-java/server/{version}"
See: PostHog/posthog#45652
Address PR review feedback to use a more specific SDK name.
16f8460 to
1f7d956
Compare
|
made the change to use |
|
In this context I agree, it's definitely way too vague. However, we have active users on the I think it's clear that some clean up is in order here, though, and possibly beyond just changing the user agent. To simplify things, I think it makes sense if we begin migrating the SDK back toward For now, we should definitely track the |
Track posthog-server user agent (deprecated, users migrating to posthog-java).
|
Thank you @igormq! |
Summary
PosthogServervariant toLibraryenum for trackingposthog-serveruser agentposthog-javaposthog-server/X.Y.Zuser agents correctlyRelated: PostHog/posthog-android#386