Open dnys1 opened 3 months ago
Would this target celest_auth
exclusively? If so, the celest_auth
package can use the native_storage
package you made, and provide a wrapper for NativeSecureStoragePlatform
(We can call it NativeAuthStoragePlatform
for the rest of this paragraph). The wrapper would just prepend the user ID found in the current auth state to the scope
the user passes in when initializing NativeAuthStoragePlatform
. Whenever the user interacts with NativeAuthStoragePlatform
, it can do a check to see if the current user can unlock the existing data. If it can, then the user owns the data and can interact with it. If it can't, then we can delete the data because we can assume the user who owned all the data is long gone. (The deleting stale data can be optional. Leaving stale data untouched can enable users to find their local data after signing back in).
Don't know if this makes sense at all or if I'm missing something. What do you think?
Hey @smrdotgg, the goal would be to include this functionality in package:native_storage
which has no dependency on Celest. And yes, Celest Auth is being migrated to native_storage
which will allow dependency injection from the developer :-)
This is basically the way I was thinking about it, too. The goal is to be able to handle account switching (multiple users signed in at once), while ensuring that re-authentication occurs as necessary. Still fleshing out the mechanism, but it'll likely work as you're describing. Glad we're on the same page!
The current local storage implementations persist across login sessions. A session storage implementation would allow persistence across app restarts but not across logins.