github-starred/android
2
0
Fork 0
mirror of https://github.com/bitwarden/android.git synced 2026-05-05 23:38:51 -05:00
Code Issues 1.1k Packages Projects Releases 122 Wiki Activity

[PR #6384] [MERGED] [PM-30899] Store account keys upon SSO user creation #48139

New Issue
Closed
opened 2026-04-26 15:39:56 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-26 15:39:56 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/bitwarden/android/pull/6384
Author: @SaintPatrck
Created: 1/20/2026
Status: ✅ Merged
Merged: 1/23/2026
Merged by: @david-livefront

Base: main ← Head: PM-30899/tde-trust-device-fix

📝 Commits (1)

📊 Changes

7 files changed (+126 additions, -32 deletions)

View changed files

📝 app/src/main/kotlin/com/x8bit/bitwarden/data/auth/repository/AuthRepositoryImpl.kt (+46 -23)
📝 app/src/test/kotlin/com/x8bit/bitwarden/data/auth/repository/AuthRepositoryTest.kt (+21 -3)
📝 network/src/main/kotlin/com/bitwarden/network/api/AuthenticatedAccountsApi.kt (+4 -1)
➕ network/src/main/kotlin/com/bitwarden/network/model/CreateAccountKeysResponseJson.kt (+27 -0)
📝 network/src/main/kotlin/com/bitwarden/network/service/AccountsService.kt (+5 -1)
📝 network/src/main/kotlin/com/bitwarden/network/service/AccountsServiceImpl.kt (+2 -1)
📝 network/src/test/kotlin/com/bitwarden/network/service/AccountsServiceTest.kt (+21 -3)

📄 Description

🎟️ Tracking

PM-30899

📔 Objective

Update the createAccountKeys API call to handle and store the full response object, which includes the accountKeys.

When a new SSO user is created, the accountKeys received from the createAccountKeys endpoint are now stored in authDiskSource.

This fixes an issue where an SSO user was forced to re-authenticate after app process death, even when the device is trusted.

Specific changes include:

  • Modified AccountsService and related API definitions to expect and return a CreateAccountKeysResponseJson object instead of Unit.
  • Introduced the CreateAccountKeysResponseJson data class to model the API response.
  • Updated AuthRepositoryImpl to store the accountKeys from the response after creating a new SSO user.
  • Storing the new SSO user data in the AuthRepositoryImpl is done in a UserState to ensure state-based navigation does not occur too soon.
  • Adjusted associated tests to reflect these changes, including mocking the new response structure and verifying that accountKeys are stored correctly.

⏰ 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

  • 👍 (:+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

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/bitwarden/android/pull/6384 **Author:** [@SaintPatrck](https://github.com/SaintPatrck) **Created:** 1/20/2026 **Status:** ✅ Merged **Merged:** 1/23/2026 **Merged by:** [@david-livefront](https://github.com/david-livefront) **Base:** `main` ← **Head:** `PM-30899/tde-trust-device-fix` --- ### 📝 Commits (1) - [`3e8cba0`](https://github.com/bitwarden/android/commit/3e8cba0d4dc078e915eba90c3d6985cc99f4a888) [PM-30899] Store account keys on new user creation ### 📊 Changes **7 files changed** (+126 additions, -32 deletions) <details> <summary>View changed files</summary> 📝 `app/src/main/kotlin/com/x8bit/bitwarden/data/auth/repository/AuthRepositoryImpl.kt` (+46 -23) 📝 `app/src/test/kotlin/com/x8bit/bitwarden/data/auth/repository/AuthRepositoryTest.kt` (+21 -3) 📝 `network/src/main/kotlin/com/bitwarden/network/api/AuthenticatedAccountsApi.kt` (+4 -1) ➕ `network/src/main/kotlin/com/bitwarden/network/model/CreateAccountKeysResponseJson.kt` (+27 -0) 📝 `network/src/main/kotlin/com/bitwarden/network/service/AccountsService.kt` (+5 -1) 📝 `network/src/main/kotlin/com/bitwarden/network/service/AccountsServiceImpl.kt` (+2 -1) 📝 `network/src/test/kotlin/com/bitwarden/network/service/AccountsServiceTest.kt` (+21 -3) </details> ### 📄 Description ## 🎟️ Tracking [PM-30899](https://bitwarden.atlassian.net/browse/PM-30899) ## 📔 Objective Update the `createAccountKeys` API call to handle and store the full response object, which includes the `accountKeys`. When a new SSO user is created, the `accountKeys` received from the `createAccountKeys` endpoint are now stored in `authDiskSource`. This fixes an issue where an SSO user was forced to re-authenticate after app process death, even when the device is trusted. Specific changes include: - Modified `AccountsService` and related API definitions to expect and return a `CreateAccountKeysResponseJson` object instead of `Unit`. - Introduced the `CreateAccountKeysResponseJson` data class to model the API response. - Updated `AuthRepositoryImpl` to store the `accountKeys` from the response after creating a new SSO user. - Storing the new SSO user data in the `AuthRepositoryImpl` is done in a UserState to ensure state-based navigation does not occur too soon. - Adjusted associated tests to reflect these changes, including mocking the new response structure and verifying that `accountKeys` are stored correctly. ## ⏰ 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 [PM-30899]: https://bitwarden.atlassian.net/browse/PM-30899?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-26 15:39:56 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
app:authenticator
app:password-manager
bug
bug-passkey
customer-support
duplicate
enhancement
good first issue
help wanted
needs-reply
needs-response
pull-request
Mirrored from GitHub Pull Request
 question
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/android#48139
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?