[PM-12612] SDK-Managed Repository support #301
Draft
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 |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #301 +/- ##
==========================================
- Coverage 71.38% 70.66% -0.73%
==========================================
Files 237 239 +2
Lines 18938 19135 +197
==========================================
+ Hits 13519 13521 +2
- Misses 5419 5614 +195 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
dani-garcia
force-pushed
the
ps/state-impl
branch
from
a753607 to
5b9dd03
Compare
dani-garcia
added a commit
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
# Conflicts: # Cargo.lock # crates/bitwarden-state/Cargo.toml # crates/bitwarden-state/src/registry.rs # crates/bitwarden-state/src/repository.rs # crates/bitwarden-vault/src/cipher/cipher.rs # Conflicts: # crates/bitwarden-vault/src/vault_client.rs # Conflicts: # Cargo.lock # crates/bitwarden-state/Cargo.toml Use bundled sqlite to solve compile issues Update readme Don't stringify the data in indexeddb Remove the comment Update readme
dani-garcia
force-pushed
the
ps/state-impl
branch
from
8602563 to
5e9d57a
Compare
…es (#329) ## 🎟️ Tracking <!-- Paste the link to the Jira or GitHub issue or otherwise describe / point to where this change is coming from. --> ## 📔 Objective <!-- Describe what the purpose of this PR is, for example what bug you're fixing or new feature you're adding. --> ## ⏰ 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
|
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-12612
📔 Objective
A continuation of #213, this PR implements some demo SDK managed data store based on SQLite (on non-wasm) and IndexedDB (on wasm). The client implementation of both these PRs is in bitwarden/clients#14839
Both databases are wrapped in a Database trait and conditionally compiled based on platform. Then from each database we can get multiple
Repositoryimplementations that can be used to read and write data persistently. Each repository is mapped to a separate table in SQLite and Object Store in IndexedDb.Some limitations of the current system:
ClientSettingsmaybe?⏰ Reminders before review
team
🦮 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 confirmedissue 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