Open jneterer opened 1 year ago
May have answered my own question here: https://capacitorjs.com/docs/guides/storage.
"...your app needs to expect that the data will be lost eventually. This is because the OS will reclaim local storage from Web Views if a device is running low on space."
Although my device isn't low on storage, there could be other reasons the OS would evict the space.
@j-berman Looking for your thoughts here. For Capacitor applications that use Userbase, local storage is not a long-term data storage solution, as the data can get cleared and session lost. I used patch-package to prove replace local storage with this capacitor plugin (UserDefaults on iOS, SharedPreferences on Android, local storage on web). It works on all 3 platforms and successfully maintains user sessions.
The question is this, should I:
@capacitor-community/userbase
or something) where the only difference is capacitor support? The new project could like here with the Capacitor Community.Perhaps there's a simpler way to create a new Capacitor plugin that has both userbase-js
and path-package
as dependencies?
I did something similar for the Cordova plugin, which needed to use a custom scrypt
plugin for the password hashing algorithm. The Cordova plugin overrides the password hashing algorithm used by userbase-js
internally by overriding a passwordHashAlgo
param in signUp
, signIn
, and updateUser
:
Maybe there's an even simpler way to do it in this case.
It might end up being more effort than it's worth if you can just use path-package
in your app though. Perhaps if others express interest in a Capacitor plugin then it's worth exploring the plugin route further. Your call :)
@j-berman wow, for some reason I wasn't aware of the Cordova plugin, or I forgot about it! I may be able to use the Cordova plugin in place of the regular userbase-js package. I'll test it out later today.
I will say that updating to use the new storage method did not work for me. I checked the app this morning and was signed out. So my session lasted maybe 6 days. Maybe the Cordova plugin will be better!
@j-berman would be curious if you're using the Cordova plugin and if you've had session issues? I suppose it could have to do with my implementation, maybe a race condition with init or something, but I really don't think so.
I've just come to realize this is only an issue on iOS. I just picked up an old Android phone for testing, opened the app, and my session from months ago was still active and working as expected.
@j-berman Can you explain why expirationDate
behaves this way?
When I sign in, my userbaseCurrentSession
has a value of:
{
"username": "jneterer",
"signedIn": true,
"sessionId": "...",
"creationDate": "2022-12-09T05:21:46.989Z",
"expirationDate": "2023-12-09T05:21:46.989Z"
}
However when I close/refresh the browser tab or window/app and open it again, my expirationDate
is now only only 24 hours from now (instead of 365 days as set on sign in, see above). Every subsequent close+open adds 24 hours to the expiration date.
{
"username": "jneterer",
"signedIn": true,
"sessionId": "...",
"creationDate": "2022-12-09T05:21:46.989Z",
"expirationDate": "2022-12-10T05:22:24.319Z"
}
Wondering if this has anything to do with it. Maybe not.
Sounds like this might be the issue you're running into!
When a user resumes a session via init
, Userbase will set the session to expire 24 hours from that point in time by default. You would have to set sessionLength
in init
in order to have the session extend your desired length.
This is odd behavior on Userbase's end. If sessionLength
isn't provided in init
, then it should stick with the session the user already has going (the expiration should not change). That seems more reasonable/what you were expecting too.
Separately, have you double checked to see that Capacitor is indeed clearing local storage? It sounds like the above may have been the root cause of the issue here.
Maybe it is! The only thing that makes me think it may not be, is this isn't an issue on Android. I just opened the app up a test device that I hadn't picked up for months and I was still signed in.
Wow, I didn't realize you had to set sessionLength
on init
. I'll have to try that and see if it makes a difference. I agree, if it isn't provided in init
, it should respect what was set on signIn
.
I'm going to have to re-verify. I switched to using the preferences capacitor plugin to test if that would persist the session (uses UserDefaults on iOS and SharedPreferences on Android), but it didn't, which might come back to the init
problem. I'll have to do another test to see but without the storage modification.
@j-berman Results from two tests on iOS:
sessionLength
on init
. Result - open more than 24 hours after sign in, logged out.sessionLength
on init
to 365. Result - open more than 24 hours after sign in, still logged in.The above is also true on the web. I don't believe this is happening on Android, but it doesn't make sense why not.
I think the solution is two part:
sessionLength
on init
(however should probably be updated in a PR to by default respect the value given on signIn
)
When setting
rememberMe: 'local'
andsessionLength: 8760
(1 year), the session consistently ends early. The user's session usually lasts just a few days, max. This isn't as reproducible on web as it is in an Ionic+Capacitor mobile application where it happens every time.It could be an issue with the Capacitor layer that allows for "local storage" access in a Web Native app, but I'm not sure. I wanted to call it out here as well in case there might be any insights as to why this is occurring.