Repository navigation
feat(flags): support obfuscated assignment keys - #265
Open
leoromanovsky wants to merge 4 commits into
Open
leoromanovsky wants to merge 4 commits into
leoromanovsky wants to merge 4 commits into
Conversation
❌ ErrorsYour PR has failed checks. Please review the issues below and take necessary action before merging. 🚦 2 Pipeline jobs failed
Useful? React with 👍 / 👎 This comment will be updated automatically if new data arrives.🔗 Commit SHA: c42e1f2 | Docs | View more details | Give us feedback! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tracking: FFLSDK-263
Motivation
Readable flag keys can reveal upcoming features. Support obfuscated assignments without changing application evaluation calls.
This reduces readable names in payloads; it does not hide values or prevent dictionary guessing. It is not encryption or response signing.
Changes and Decisions
Advertise support through this header instead of a JSON
supported_capabilitiesfield. Existing request fields stay unchanged.X-DD-FEATURE-FLAGS-CAPABILITIES: assignment-encoding-flag-key-256-v1Capabilities are sorted and comma-separated. They describe support, not a requirement. The edge still selects plaintext or obfuscated responses through its rollout.
For
obfuscated: true, validateobfuscation: {scheme, salt}and hash the application key for lookup. The response scheme remainsflag-key-sha256-v1:The public salt contains 16 bytes, encoded as 32 lowercase hexadecimal characters. Keys use exact UTF-8 bytes without normalization.
sequenceDiagram participant App participant SDK as Unity Flags client participant Edge as Fastly SDK->>Edge: Precompute request + capability header Edge-->>SDK: Plaintext, or encoded keys + scheme + salt SDK->>SDK: Validate and retain assignments with encoding App->>SDK: Evaluate original flag key SDK->>SDK: Hash lookup key only for encoded assignments SDK-->>App: Original value and evaluation details SDK->>SDK: Keep original flag key in telemetrySystem.Security.Cryptography.SHA256. Keep encoded assignments and their metadata together in memory.UnityWebRequestin a mobile player remains unverified. The local transport harness does not establish IL2CPP behavior.Release requires edge support for the new header. This PR does not deploy backend changes.
Related: edge rollout, browser implementation.