-
Notifications
You must be signed in to change notification settings - Fork 46
fix: Add validation format check for SDK key #351
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
fix: Add validation format check for SDK key #351
Conversation
- Add validate_sdk_key function to prevent logging invalid SDK keys - Validate SDK key format in Config constructor - Add comprehensive tests for SDK key validation - Follow existing validation patterns in codebase Prevents logging of invalid SDK keys by validating that they contain only visible ASCII characters suitable for HTTP headers. Invalid keys trigger a ValueError with a generic message that doesn't expose the actual key value. Co-Authored-By: jbailey@launchdarkly.com <accounts@sidewaysgravity.com>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
- Update test_validate_sdk_key_non_string to actually test non-string inputs - Test various non-string types: int, None, object, list, dict - Verify proper error message is logged for each invalid type Co-Authored-By: jbailey@launchdarkly.com <accounts@sidewaysgravity.com>
- Rename validate_sdk_key to is_valid_sdk_key_format - Use dotnet regex pattern ^[-a-zA-Z0-9._]+$ instead of HTTP header validation - Add maximum length validation of 8192 characters - Change from raising ValueError to silently not setting invalid keys - Update all tests to expect silent failure instead of exceptions - Update documentation to reflect new behavior Co-Authored-By: jbailey@launchdarkly.com <accounts@sidewaysgravity.com>
- Address GitHub comment about missing docstring format - Follow Python conventions for function documentation Co-Authored-By: jbailey@launchdarkly.com <accounts@sidewaysgravity.com>
GitHub Response to jsonbailey's commentHi @jsonbailey, I believe there may be some confusion about the current implementation. The diff you're referencing shows the old approach that raised a The current code in if is_valid_sdk_key_format(sdk_key):
self.__sdk_key = sdk_key
else:
self.__sdk_key = None This matches the dotnet SDK behavior where invalid keys are silently set to Could you clarify what specific issue you're seeing with the current implementation? I want to make sure I address any concerns properly. |
Devin is archived and cannot be woken up. Please unarchive Devin if you want to continue using it. |
🤖 I have created a release *beep* *boop* --- ## [9.12.1](9.12.0...9.12.1) (2025-09-30) ### Bug Fixes * Add validation format check for SDK key ([#351](#351)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). <!-- CURSOR_SUMMARY --> --- > [!NOTE] > Release 9.12.1 with SDK key format validation bug fix and version/provenance updates. > > - **Release 9.12.1**: > - Bump version to `9.12.1` in `pyproject.toml`, `ldclient/version.py`, and `.release-please-manifest.json`. > - Update `CHANGELOG.md` with bug fix: add SDK key format validation. > - Update `PROVENANCE.md` example `SDK_VERSION` to `9.12.1`. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 7da6750. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Jason Bailey <jbailey@launchdarkly.com>
Fix SDK Key Format Validation to Prevent Logging Invalid Keys
This PR implements SDK key format validation to prevent logging of potentially sensitive invalid SDK keys, aligning the Python SDK with the .NET SDK implementation.
Requirements
Related issues
Addresses security concern where invalid SDK keys could be logged, potentially exposing sensitive information. Based on similar validation implemented in dotnet-core PR #163 and PR #162.
Describe the solution you've provided
Key Changes:
New validation function: Added
is_valid_sdk_key_format()
inldclient/impl/util.py
that validates SDK keys using:^[-a-zA-Z0-9._]+$
(matching .NET SDK)Silent failure behavior: Modified
Config
constructor andcopy_with_new_sdk_key()
to silently set invalid keys toNone
instead of raisingValueError
exceptionsComprehensive test coverage: Added tests for valid keys, invalid keys, edge cases (empty/None/non-string), and maximum length validation
Security Benefit:
Invalid SDK keys are now prevented from entering the system, eliminating the risk of them being logged elsewhere in the codebase.
Critical Review Points:
^[-a-zA-Z0-9._]+$
exactly matches the .NET SDK implementationNone
SDK keysDescribe alternatives you've considered
Additional context
Note
Add strict SDK key validation (length/characters) and integrate into Config; standardize constants; add comprehensive tests.
validate_sdk_key_format
inldclient/impl/util.py
enforcing allowed characters and max length (8192), returning''
on invalid and logging warnings.Config
(ldclient/config.py
) to set__sdk_key
; updatecopy_with_new_sdk_key
behavior accordingly._validate
inConfig
to warn on missing/blank SDK key with updated message.impl/util.py
(e.g.,_retryable_statuses
→_RETRYABLE_STATUSES
) and update references.ldclient/testing/impl/test_util.py
covering valid/invalid/non-string/empty/None/max-length SDK keys.ldclient/testing/test_config.py
to verify SDK key validation, copy behavior, and max length handling.Written by Cursor Bugbot for commit 6ec6770. This will update automatically on new commits. Configure here.
BEGIN_COMMIT_OVERRIDE
fix: Add validation format check for SDK key
END_COMMIT_OVERRIDE