feat: guard the primary mobile key against the secondary keys - #518
Closed
abelonogov-ld wants to merge 1 commit into
Closed
feat: guard the primary mobile key against the secondary keys#518abelonogov-ld wants to merge 1 commit into
abelonogov-ld wants to merge 1 commit into
Conversation
setSecondaryMobileKeys rejects a key the primary environment already uses, but the primary key could then be assigned to one of those keys afterwards, reaching a state neither call would have accepted. Setting it now goes through setMobileKey, which makes the same check the other way around, so the order the two are called in no longer decides whether the configuration is validated. The property stays settable within the SDK, which assigns it on a copy of the config for each environment it starts. BREAKING CHANGE: LDConfig.mobileKey is read-only outside the SDK. Assignments to it become calls to the throwing setMobileKey. Co-authored-by: Cursor <cursoragent@cursor.com>
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
1 participant
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.
setSecondaryMobileKeys rejects a key the primary environment already uses, but the primary key could then be assigned to one of those keys afterwards, reaching a state neither call would have accepted. Setting it now goes through setMobileKey, which makes the same check the other way around, so the order the two are called in no longer decides whether the configuration is validated.
The property stays settable within the SDK, which assigns it on a copy of the config for each environment it starts.
BREAKING CHANGE: LDConfig.mobileKey is read-only outside the SDK. Assignments to it become calls to the throwing setMobileKey.
Requirements
Related issues
Provide links to any issues in this repository or elsewhere relating to this pull request.
Describe the solution you've provided
Provide a clear and concise description of what you expect to happen.
Describe alternatives you've considered
Provide a clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context about the pull request here.
Note
Overview
Closes a validation gap where
setSecondaryMobileKeysrejected a primary key collision, but assigning the primary key afterward could still create the same invalid config.LDConfig.mobileKeyis nowpublic internal(set), with a new throwingsetMobileKey(_:)that rejects keys already used by a secondary environment. The Objective-C wrapper mirrors this. The SDK still assignsmobileKeydirectly on per-environment config copies during startup.Breaking change: external assignments to
mobileKeymust becometry setMobileKey(...).Reviewed by Cursor Bugbot for commit 0008e58. Bugbot is set up for automated code reviews on this repo. Configure here.