-
Notifications
You must be signed in to change notification settings - Fork 1k
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
bug: cookies not being persisted #3012
Comments
Simply adding the following to my import android.webkit.CookieManager;
public class MainActivity extends BridgeActivity {
// ...
@Override
public void onPause() {
super.onPause();
CookieManager.getInstance().flush();
}
// ...
} |
I can confirm that @IlCallo solution indeed solves the problem, but shouldn't this be achieved by Capacitor itself? Or at least be part of Android template for new projects? As the current behavior (cookie state not being immediately persisted on Android) is definitely unexpected. |
Yep, just had this happen to me. I released another Capacitor App last year and the Android Cookies were being persisted correctly, but were reset on iOS. That was fixed somewhere server-side. Unfortunately something must've changed with Android and now the cookies are being reset on closing the app. Adding the code in the OP seems to fix it for now. |
Thank you. This should be implemented by default definitely. |
@malte94 @creativiii did you fully solved the problem on both iOS and Android ? What do you mean by OP ? Can you give some examples ? Thanks a lot for your help |
Having the problem with Auth0 cookies, our users disconnect after 2 days on iOS and Android (seems like they are not persisted after this time) |
As mentioned, I added the code posted by @IlCallo to my Android project and it fixed the issue. I haven't dared removing it since, so I have no idea if the problem is fixed or not. |
Since the user disconnects after 2 days, this does not seem to be related to having no persistency at all, like discussed here. If you use a session cookie, set an expiration date.
|
@IlCallo solution worked perfectly for me! |
We experience the same bug |
For us it was fixed by setting a correct expires date, we always just had "session" const expires = dayjs().add(7, "days").toDate().toUTCString()
CapacitorCookies.setCookie({ key: "identifier", value: "...", expires }) |
@markemer was it solved ? |
We were having a same issue in Capacitor 5 Android. |
@markemer will you fix this problem ? |
The team's official explanation is that Capacitor cookies should not be used because they are only intended for the web: https://forum.ionicframework.com/t/cookies-vs-preferences-what-is-more-persistent/236820/4?u=mariusbolik |
@mariusbolik thanks a lot, tools like auth0 use the browser cookies for example, so how to fix the problem ? |
Thanks for the issue! This issue is being locked to prevent comments that are not relevant to the original issue. If this is still an issue with the latest version of Capacitor, please create a new issue and ensure the template is fully filled out. |
Bug Report
Capacitor Version
npx cap doctor
output:@capacitor/ios not installed
@capacitor/cli 1.5.2
@capacitor/core 1.5.2
@capacitor/android 2.1.0
Affected Platform(s)
Current Behavior
Android native Cookies management persists cookies only after a given amout of time.
This causes problems when an auth session cookie or remember me cookie are used and the application is destroyed shortly after the login (or any other action creating a cookie) is performed.
When re-started, we won't have that cookie available.
A similar problem is present on iOS too, but haven't yet tried it out (link at the end of the issue).
Expected Behavior
Cookies shall be forcefully persisted when
onPause
oronStop
is called, to be sure to avoid data loss in case the app is later destroyed (by the user or by the system).Sample Code or Sample Application Repo
Reproduction Steps
Other Technical Details
yarn --version
output: 1.22node --version
output: 13.xOther Information
This article explain the problem pretty well.
#2347 seems to report the same problem
#2831 seems to be related, but not sure
The text was updated successfully, but these errors were encountered: