Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow users to change options #75

Open
luckyrat opened this issue Jul 6, 2022 · 1 comment
Open

Allow users to change options #75

luckyrat opened this issue Jul 6, 2022 · 1 comment

Comments

@luckyrat
Copy link
Contributor

luckyrat commented Jul 6, 2022

At the moment the app using this plugin has to be forcibly restarted to change the options such as authenticationValidityDurationSeconds.

It would be good to be able to allow the storage options to be changed after the first initialisation.

The solution I currently use in Kee Vault is to change the behaviour of the forceInit flag, as can be seen in this commit: kee-org@59f2819

However, I misunderstood the intention of that flag so it is probably not the right approach for us to take in the long run.

@hpoul has suggested "something like a deleteAndDispose which deletes the storage, clears the key and removes the storage file from the dictionary.. and after disposing you have to initialize it again".

I think that could work but maybe it would be neater if the consumer didn't have to keep track of the state of whether the storage file dictionary has been initialised. Although in my current implementation in Kee Vault I effectively already do this by caching the storage instance, there might be some app architectures for which it would be necessary for this library to handle that state without throwing an exception.

The library could store the currently active InitOptions and, perhaps gated by a new flag on getStorage, reinitialise the storage if a different set of options are supplied?

@abdallah-odeh
Copy link

Is this implemented in any way?
This feature is really needed!
let's take the following scenario:
using OAuth, the user logs in, biometric auth request will be permitted to save the refresh_token,
after 5 minutes, the user is still in the app playing around!, the access_token expired,
assume we have the refresh_token stored in a variable and we don't need to read it again from storage (reduced 1 authentication request),
new access_token & refresh_token are received!,
we need to save the new refresh_token for future usages (if the user closed the app and reopened it), here the plugin requests a new biometric authentication & we must authenticate to write the new value.

implementing the feature of dispose the storage and reinitialize it again with different options will be great

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants