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
{{ message }}
This repository was archived by the owner on Aug 21, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Aug 21, 2026. It is now read-only.
The current local storage implementations persist across login sessions. A session storage implementation would allow persistence across app restarts but not across logins.
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!
Activity
smrdotgg commentedon May 4, 2024
Would this target
celest_authexclusively? If so, thecelest_authpackage can use thenative_storagepackage you made, and provide a wrapper forNativeSecureStoragePlatform(We can call itNativeAuthStoragePlatformfor the rest of this paragraph). The wrapper would just prepend the user ID found in the current auth state to thescopethe user passes in when initializingNativeAuthStoragePlatform. Whenever the user interacts withNativeAuthStoragePlatform, 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?
dnys1 commentedon May 5, 2024
Hey @smrdotgg, the goal would be to include this functionality in
package:native_storagewhich has no dependency on Celest. And yes, Celest Auth is being migrated tonative_storagewhich 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!
feat(cli): Implement `api.anonymous` (#100)