[PM-19479] Client-Managed SDK state definition #14839
Open
+94
−0
Conversation
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
|
Great job, no security vulnerabilities found in this Pull Request |
# Conflicts: # libs/common/src/platform/services/sdk/default-sdk.service.ts
This was referenced Jun 9, 2025
dani-garcia
added a commit
to bitwarden/sdk-internal
that referenced
this pull request
Jun 24, 2025
## 🎟️ Tracking https://bitwarden.atlassian.net/browse/PM-19479 ## 📔 Objective Implement a generic trait for accessing the client application's data storage directly. Because we want the store access to be typed, but `bitwarden_core` isn't aware of the models, `bitwarden_core` only implements a generic way to set and retrieve generic `impl Repository<T>` instances, somewhat like dependency injection. Then it's up to each team/feature crates to define which models and which stores are available. This feature is created in a new `bitwarden-state`, which will be expanded by a separate PR with the addition of SDK-managed state (Sqlite+IndexedDB). At the moment this crate contains: - A `Repository` trait which will be implemented by the clients (and the SDK in the future), and a `RepositoryItem` marker trait which will be used to mark which models are meant to be used with the repositories. - A `StateRegistry` which stores all the client-managed Repositories, and in the future will also handle the SDK-managed repositories. - A new `StateClient` subclient under platform that will be used by the applications to register their Repositories. Both the WASM and UniFFI crates also need some conversion code to implement the `Repository` traits. I've tried to simplify it as much as possible, and hide it behind a macro when that wasn't possible. Some limitations on the current design: - The current integration with web clients requires the State Provider definition to be `UserKeyDefinition<Record<string, T>>` to match the key-value pattern in `Repository`. This usually matches with what is being used for vault (encrypted ciphers/folders, etc), but it might fall short on other domains, like profile data, or user keys. - There's no great way of ensuring that all the client-managed Repositories have been registered, other than keeping a list. I've tried to use the `inventory` crate to keep a global list of all the existing implementations and then validating that they've all been registered, but that doesn't work for WASM. We might be able to use the `inventory` crate and just run it in tests though. For some documentation on how to use it, you can check the README: https://github.com/bitwarden/sdk-internal/blob/ps/state-traits/crates/bitwarden-state/README.md The continuation of this is in #301, which contains SDK managed repository support. The client implementation of both these PRs is in bitwarden/clients#14839 ## ⏰ Reminders before review - Contributor guidelines followed - All formatters and local linters executed and passed - Written new unit and / or integration tests where applicable - Protected functional changes with optionality (feature flags) - Used internationalization (i18n) for all UI strings - CI builds passed - Communicated to DevOps any deployment requirements - Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team ## 🦮 Reviewer guidelines <!-- Suggested interactions but feel free to use (or not) as you desire! --> - 👍 (`:+1:`) or similar for great changes - 📝 (`:memo:`) or ℹ️ (`:information_source:`) for notes or general info - ❓ (`:question:`) for questions - 🤔 (`:thinking:`) or 💭 (`:thought_balloon:`) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion - 🎨 (`:art:`) for suggestions / improvements - ❌ (`:x:`) or⚠️ (`:warning:`) for more significant problems or concerns needing attention - 🌱 (`:seedling:`) or ♻️ (`:recycle:`) for future improvements or indications of technical debt - ⛏ (`:pick:`) for minor or nitpick changes
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## main #14839 +/- ##
==========================================
- Coverage 36.91% 36.91% -0.01%
==========================================
Files 3232 3233 +1
Lines 93590 93625 +35
Branches 14084 14087 +3
==========================================
+ Hits 34552 34559 +7
- Misses 57602 57630 +28
Partials 1436 1436 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
|
@shane-melton @gbubemismith @Jingo88 Adding you as reviewers just to make sure you see this as it implements |
nick-livefront
approved these changes
Jul 2, 2025
| @@ -409,3 +412,17 @@ export class Cipher extends Domain implements Decryptable<CipherView> { | |||
| return sdkCipher; | |||
| } | |||
| } | |||
|
|
|||
| export class CipherRecordMapper implements SdkRecordMapper<CipherData, SdkCipher> { | |||
There was a problem hiding this comment.
🎨 non blocking and could always be done in the future: I probably would put this into a separate file only to keep this file dedicated to Cipher
gbubemismith
approved these changes
Jul 2, 2025
| @@ -409,3 +412,17 @@ export class Cipher extends Domain implements Decryptable<CipherView> { | |||
| return sdkCipher; | |||
| } | |||
| } | |||
|
|
|||
| export class CipherRecordMapper implements SdkRecordMapper<CipherData, SdkCipher> { | |||
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
https://bitwarden.atlassian.net/browse/PM-19479
https://bitwarden.atlassian.net/browse/PM-22593
📔 Objective
Initial setup of the Client-managed SDK state framework for the TS clients. This framework connects directly with State Providers and requires users to implement a
SdkRecordMapperto return the user key definition, and define conversion to and from SDK objects. At the moment only Record based user key definitions are supported.This also implements support for Ciphers as an example, but only for read-only operations, as the SDK->TS conversion is not implemented yet. I've placed the
SdkRecordMapperin the same file where the model is defined, but let me know if you can think of a better place for it.📸 Screenshots
⏰ Reminders before review
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes