You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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
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?
The text was updated successfully, but these errors were encountered: