Skip to content
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

Cookies not stored on first application launch #802

Closed
3 tasks done
kirkHawksworth opened this issue Aug 7, 2019 · 16 comments
Closed
3 tasks done

Cookies not stored on first application launch #802

kirkHawksworth opened this issue Aug 7, 2019 · 16 comments

Comments

@kirkHawksworth
Copy link

kirkHawksworth commented Aug 7, 2019

Bug Report

Problem

When installing app for the very first time, session cookies returned in a response to a $.ajax call are not stored.
After a force close of the app and a restart, everything works as expected.

What is expected to happen?

Set-Cookie response from the server should store the cookies on the device

What does actually happen?

Cookies are not stored, subsequent $.ajax calls are therefore unauthenticated

Information

An identical issue occurred on iOS in 2018.
ionic-team/cordova-plugin-ionic-webview#22

There were a lot of plugins created to fix this issue, but they're iOS only.

This may be an underlying WebView issue, I'm not sure.

If I disable Chrome on my device (I can't uninstall it), then re-install the app, everything works as expected. Re-enabling Chrome then stops the cookie from being stored on the first launch.

With latest version of Chrome installed and enabled on my device, my request is submitted with the following user string:

Mozilla/5.0 (Linux; Android 9; SM-N960F Build/PPR1.180610.011; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/76.0.3809.89 Mobile Safari/537.36

This doesn't work on first application launch.

If I disable Chrome, my request is submitted with the following user string:

Mozilla/5.0 (Linux; Android 9; SM-N960F Build/PPR1.180610.011; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/72.0.3626.121 Mobile Safari/537.36

Which does work on first application launch.

edit: It seems Google made some changes to WebView in v9+
https://developer.android.com/about/versions/pie/android-9.0-changes-28#web-data-dirs
In my rudimentary testing so far, this issue only seems to impact v9 Android

Command or Code

I can submit a sample Cordova App pointing to one my public test servers if this would help?

Environment, Platform, Device

Android.

Version information

Cordova:
Cordova version: 8.1.2, Android 7.1.4
Cordova version: 9.0.0, Android 8.0.0
(tested on both)

WebView version:
packageName: "com.google.android.webview"
versionCode: 362612100
versionName: "72.0.3626.121"

Device Version:
Samsung GalaxyNote9
Android Version 9

Checklist

  • I searched for existing GitHub issues
  • I updated all Cordova tooling to most recent version
  • I included all the necessary information above
@alfarafaelm
Copy link

I have the same issue

1 similar comment
@devjva
Copy link

devjva commented Aug 8, 2019

I have the same issue

@breautek
Copy link
Contributor

breautek commented Aug 8, 2019

If someone can provide a minimal reproduction repository that demonstrates this issue I'll be happy to look at it.

Thanks.

@devjva
Copy link

devjva commented Aug 8, 2019

@kirkHawksworth
Copy link
Author

kirkHawksworth commented Aug 9, 2019

Thanks for the link @devjva it looks like that is indeed the issue.

It seems to be fixed in Chrome 77+, they've also committed to doing a respin of 76 to fix this issue

There are a couple of workaround suggested in that thread, most useful is probably the quick restart of the application

https://bugs.chromium.org/p/chromium/issues/detail?id=991107#c19

right now we considering to use this plugin (https://github.com/dpa99c/cordova-diagnostic-plugin#readme) and do automatic restart for users for first time

just for example:
if(!window.localStorage.getItem('__isFirstAppLoad')) {
window.localStorage.setItem('__isFirstAppLoad', 'false');
if(cordova && cordova.plugins && cordova.plugins.diagnostic){
cordova.plugins.diagnostic.restart(function () { }, false);
}
}

I'm going to close this issue too as it's an underlying bug in WebView, not Cordova.

@th3hamm0r
Copy link

I've the same issue, but actually it looks like after a fresh install or a data wipe, cookies which are set often don't remain after a force close of the app. This does not only happen on the first start, but often also on subsequent starts.

For example:

  1. Fresh start after a data wipe
  2. In our case a privacy popup inside an iframe sets some cookies.
  3. Force close the app
  4. The cookies do not exist anymore. New cookies are created.
  5. Force close the app
  6. Again, the cookies do not exist anymore.

Only after some time navigating through the app and using some other iframes for this domain, the cookies seem to stay. But maybe the reason for the remaining cookies is not because of the user's navigation. I really don't know...
We've reproduced this with several devices from android 5 to 9, and also with the chromium 77 engine.

@th3hamm0r
Copy link

lol, I just found this https://issues.apache.org/jira/browse/CB-13456, which exactly describes my problem, and it is true, after some time (eg. 30s), the cookies are not lost.

@smalluban
Copy link

@th3hamm0r We've got the same issue in our application. After the investigation, I think there might not be a simple solution on cordova-android side, as from API 21 sync between WebView and CookieManager is done automatically - and I believe that this is a reason for 30 seconds delay. It simply has to have a 30-second timer :P

However, I have found Cordova plugin (#802 (comment)), which exposes the flush method from the CookieManager. If you call that method after your request with set-cookie, it will immediately save cookies to persist storage. The original source of the plugin does not include package.json file, so be welcome to use our fork: https://github.com/surgeventures/cordova-plugin-cookie-manager

In our code immediately after login/logout action we call for andriod:

window.cordova.plugins.CookieManagementPlugin.flush();

@guirip
Copy link

guirip commented Dec 10, 2019

Thank you very much @smalluban 🎉
It saved our asses.

@kfrederix
Copy link

@smalluban your comment saved my day as well. Thanks!

@webprogrammierer
Copy link

In our code immediately after login/logout action we call for andriod:

window.cordova.plugins.CookieManagementPlugin.flush();

Thank you very much. This helped me to solve a similar problem on a completlety different Webview App.

@dbessa1
Copy link

dbessa1 commented Aug 12, 2021

@smalluban thank you. Seu plugin funcionou perfeitamente para mim.
Há mais de 3 anos eu convivi com este problema e você resolveu! Parabéns!

@signalpoint
Copy link

signalpoint commented Apr 8, 2022

I am experiencing a very similar issue. Cookies from the web server are not being saved with cordova and android.

My last publication to Google Play was in February of 2021. At that time, I had no issues with cookies, and cordova android 9. Based on that timing, and the fact that this issue here was created in August of 2019, I was skeptical of the suggestions mentioned above, and unfortunately using window.cordova.plugins.CookieManagementPlugin.flush(); is not working for me.

I came across the blog post announcing Cordova Android 10, which mentions WebViewAssetLoader Support and:

... this is a breaking change that will cause data associated with the file:// scheme, such as cookies, ..., to be lost.

They mentioned you can revert this change by adding this to the config.xml file:

<preference name="AndroidInsecureFileModeEnabled" value="true" />

That fixed it for me!

However, I am worried that once I try to publish the application to Google Play it will be rejected because the blog post says:

Setting this flag will keep the content on the file:// scheme, which Google reports to be insecure.

I will return here and update my comment when I find out. I hope this is helpful to others!

UPDATE: I was able to publish the application to Google Play without issue.

UPDATE 2023: I still need to add the AndroidInsecureFileModeEnabled preference to my config.xml to get cookies to work properly.

@breautek
Copy link
Contributor

breautek commented Apr 8, 2022

However, I am worried that once I try to publish the application to Google Play it will be rejected because the blog post says:

I think lots of people still run with this option, so I don't think Google will block your app from the play store. I'm sure I would have heard complaints otherwise from the Cordova community. If anything, I think Google will deprecate the feature and eventually remove it, but right now it's not in a deprecated state. So I don't see that happening in the foreseeable future.

It's just a recommendation to not enable filesystem access, especially if you don't need it. Cordova always had it enabled before because Cordova always loaded files locally and there wasn't really a way not to use the file protocol until the WebViewAssetLoader.

@dpico
Copy link

dpico commented Jul 18, 2022

Hello @signalpoint ,

We have an app built with jDrupal and Cordova that's 9 years old. It's been quite a tough adventure but we have come to a dead end with the issue described in this thread. After the last PlayStore requirements came out, we updated our Cordova version and added CORS headers into our servers, but it still doesn't work. If we do a user_login, the function does it successfully and returns the login username correctly. If we do an Ajax call after that, it works.

Problem comes whenever we do a jDrupal system_connect, which returns 'anonymous user' and no further call works any longer (403 Access denied for user anonymous). We've tried to change AndroidInsecureFileModeEnabled as you suggested in this thread before and it didn't work.

@signalpoint
Copy link

@dpico Did you run things like cordova clean android and cordova prepare android after modifying the config.xml file and before running cordova build android? You can head over to the jDrupal Issue Queue to discuss further as I'd hate to pollute this thread with unrelated stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests