Allow instantiating SecureArea.CreateKeySettings object. #409
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
In order to support new kinds of SecureArea without app changes, change the SecureArea.CreateKeySettings class so it can be instantiated by apps. Also stop carrying the SecureArea class name in CreateKeySettings subclasses, instead have users of CreateKeySettings take a separate SecureArea class. Make it explicit that different SecureArea instances can be used by CredentialKey and even for different Authentication Keys. Introduce the concept of an "identifier" for a SecureArea instead of Credential, Credential.Authentiationkey, and Credential.PendingAuthenticationKey classes all using the Java class name when persisting on-disk. This paves the way to have multiple SecureArea instances of the same type but with different configuration. We'll need this for CloudSecureArea so an app can have two instances pointing to different providers, for different credentials. Also add "display name" since that is needed for Issue #380. Unfortunately this breaks the on-disk format but this is going to happen _anyway_ as we're renaming the project and moving all the code to new packages as part of the contribution of the code to the OpenWallet Foundation. In the near future we'll start committing to stable on-disk formats. For now, just update the directory used for storing data in appholder to a new location to avoid breaking existing installations. Test: All unit tests pass. Test: Manually tested
davidz25
force-pushed
the
generic-create-key-settings
branch
from
ce80ca0 to
ac69dc8
Compare
suzannajiwani
approved these changes
Nov 7, 2023
| @@ -31,7 +31,12 @@ object PreferencesHelper { | |||
| // As per the docs, the credential data contains reference to Keystore aliases so ensure | |||
| // this is stored in a location where it's not automatically backed up and restored by | |||
| // Android Backup as per https://developer.android.com/guide/topics/data/autobackup | |||
| return context.noBackupFilesDir | |||
|
|
|||
| val storageDir = File(context.noBackupFilesDir, "appholder") | |||
There was a problem hiding this comment.
What's the reasoning for changing the storage dir here?
There was a problem hiding this comment.
It's because we're breaking the on-disk format. Without this change, the application will load old data and crash. With this change, the app won't crash but it'll no credentials. At this point, such a breaking change is fine (it's just a test app after all) but as the commit message says, in the future we'll commit to stable file formats.
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.
In order to support new kinds of SecureArea without app changes, change the SecureArea.CreateKeySettings class so it can be instantiated by apps.
Also stop carrying the SecureArea class name in CreateKeySettings subclasses, instead have users of CreateKeySettings take a separate SecureArea class. Make it explicit that different SecureArea instances can be used by CredentialKey and even for different Authentication Keys.
Introduce the concept of an "identifier" for a SecureArea instead of Credential, Credential.Authentiationkey, and
Credential.PendingAuthenticationKey classes all using the Java class name when persisting on-disk. This paves the way to have multiple SecureArea instances of the same type but with different configuration. We'll need this for CloudSecureArea so an app can have two instances pointing to different providers, for different credentials. Also add "display name" since that is needed for Issue #380.
Unfortunately this breaks the on-disk format but this is going to happen anyway as we're renaming the project and moving all the code to new packages as part of the contribution of the code to the OpenWallet Foundation. In the near future we'll start committing to stable on-disk formats.
Test: All unit tests pass.
Test: Manually tested
Fixes #<issue_number_goes_here>