Make client internally mutable #837
Merged
Conversation
This file contains 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
|
No New Or Fixed Issues Found |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #837 +/- ##
==========================================
+ Coverage 59.22% 60.07% +0.85%
==========================================
Files 186 186
Lines 12396 12246 -150
==========================================
+ Hits 7341 7357 +16
+ Misses 5055 4889 -166 ☔ View full report in Codecov by Sentry. |
# Conflicts: # crates/bitwarden-uniffi/src/crypto.rs # crates/bitwarden-uniffi/src/tool/mod.rs # crates/bitwarden-uniffi/src/tool/sends.rs # crates/bitwarden-uniffi/src/vault/attachments.rs # crates/bitwarden-uniffi/src/vault/ciphers.rs # crates/bitwarden-uniffi/src/vault/collections.rs # crates/bitwarden-uniffi/src/vault/folders.rs # crates/bitwarden/src/mobile/client_crypto.rs # crates/bitwarden/src/mobile/tool/client_sends.rs
Hinton
reviewed
Jun 13, 2024
Comment on lines
72
to
74
| token: RwLock<Option<String>>, | ||
| pub(crate) refresh_token: RwLock<Option<String>>, | ||
| pub(crate) token_expires_on: RwLock<Option<i64>>, |
There was a problem hiding this comment.
I wonder if we should find some way to group these together. You shouldn't be able to write to just one of these.
There was a problem hiding this comment.
Yeah, that's true, I extracted them to a tokens struct, which at least simplifies a bit all the locking and unlocking.
# Conflicts: # crates/bitwarden/src/client/client.rs # crates/bitwarden/src/platform/fido2/authenticator.rs # crates/bitwarden/src/platform/fido2/mod.rs
Hinton
approved these changes
Jun 13, 2024
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.
📔 Objective
We're having some deadlock problems with the Passkey API by calling certain SDK functions on the
passkey-rscallbacks. These issues are caused because we're holding a reference to the RwLock during the execution of the Passkey operation and so calling into the SDK from inside that will deadlock.To solve it we can't just use a lock at the client level, and so we need to move to using interior mutability, I've revived an old PR (#70) where we started doing that.
This PR is split into two commits, for ease of review:
&mutreferences used in the bitwarden Client API. Note that this alone won't compile.Some notes of what the change entails:
EncryptionSettingsin aRwLock<Arc<>>to get the API working, this is quite unfortunate as it forces us to cloneEncryptionSettingsto modify it when callingset_org_keys. We can't wrap theorg_keysin aRwLockas we will get lifetime issues inget_key. I think the best solution for this will be the work on creating a Crypto store that only returns opaque key references, so we might want to prioritize that.external_clientfromApiConfigurations, as it's never mutated and it allows us to keep the same API forget_http_clientI hate that
MutexandRwLockreturn a Result in case they are poisoned, that's never our case and it makes their usage so cumbersome 😢Note: I've tried to change the smallest amount of code to make the change, so the secrets manager APIs (and bitwarden-json) are still mutable. If we're okay with these changes I can go back to update those in a separate PR.
⏰ 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