[Android] Cookies are not persisted across network requests

[h87kg]

Hi,

When send a GET request, tell me to login, but it's really logged in. The issue only on Android.

[mkonicek]

Hey @h87kg, can you clarify "tell me to login"? Where are you sending a GET request? Can you share your code?

[h87kg]

1. logged in successfully after invoke new AccountService.login()
2. failed without authorization after invoke new FlightService().searchFlights()

class AccountService extends Service {
  login(username, password) {
    var formData = new FormData();
    formData.append('loginName', username);
    formData.append('pwd', password);
    return fetch(`${this.URL}/sme/employee/login.json`, {
      method: 'POST',
      body: formData,
    })
    .then(response => response.json());
  }
};

class FlightService extends Service {
  searchFlights(fromCity, toCity, depDate) {
    return fetch(`${this.URL}/sme/flight.json?depCityCode=${fromCity.flightCityCode}&arrCityCode=${toCity.flightCityCode}&depDate=${DateFilter.format(depDate, 'yyyy-MM-dd')}&forBusiness=Y&isCivilServants=N`)
    .then(response => response.json());
  }
}

[h87kg]

I found the second request didn't sent the cookie info, such as:

Cookie:      PHPSESSID=jciun1hfmsqcvivvpvdbd2adp2
Cookie2:     $Version=1

POST /sme/employee/login.json

sent:

Content-Length:  32
Content-Type:    application/x-www-form-urlencoded
Host:            
Connection:      Keep-Alive

received:

Server:             nginx/1.0.15
Content-Type:       application/json;charset=UTF-8
Transfer-Encoding:  chunked
Connection:         keep-alive
Vary:               Accept-Encoding
X-Powered-By:       PHP/5.4.37
Set-Cookie:         PHPSESSID=gsdv1qgf3togdmql26pkuesiv7; path=/
Cache-Control:      no-cache
Date:               Thu, 17 Sep 2015 11:57:02 GMT
Content-Encoding:   gzip

GET /sme/flight.json?depCityCode=BJS&arrCityCode=CTU&depDate=2015-09-18&forBusiness=Y&isCivilServants=N

sent:

Host:            
Connection:       Keep-Alive
Accept-Encoding:  gzip
User-Agent:       okhttp/2.4.0

received:

Server:             nginx/1.0.15
Content-Type:       application/json;charset=UTF-8
Transfer-Encoding:  chunked
Connection:         keep-alive
Vary:               Accept-Encoding
X-Powered-By:       PHP/5.4.37
Set-Cookie:         PHPSESSID=bu8drc39vp7rkr90j3i5eji7j1; path=/
Cache-Control:      no-cache
Date:               Thu, 17 Sep 2015 11:57:06 GMT
X-Debug-Token:      22f42f
Content-Encoding:   gzip

[mkonicek]

Thanks for the detailed report! I think @andreicoman11 might know about cookies.

[jhen0409]

Maybe and this related: https://github.com/github/fetch#sending-cookies

[mbrock]

credentials: 'same-origin' doesn't help on Android, but works fine on iOS.

This can be easily tested by requesting http://httpbin.org/cookies/set?foo=bar and then http://httpbin.org/cookies.

The Set-Cookie header is also hidden from the headers object so there seems to be no way of using cookies on Android.

[arsham-f]

I'm having this same issue. Apparently the network stack on iOS automatically retains the cookies, but Android doesn't. This is a pretty big showstopper because you can't keep any sessions with remote APIs.

[CCoffie]

+1

[mkonicek]

Looks like credentials: 'same-origin' should indeed work: https://github.com/github/fetch#sending-cookies.

The way the cookies are handled should probably respect the same origin policy? What does the spec say?

Might be just not implemented yet. Will check with @andreicoman11. Would be awesome if you can point to the Java file where we are not persisting the cookies :)

[dizlexik]

Yeah I agree with @arsham-f, this is a pretty big showstopper as I am working on a project right now with a requirement to use a session-based API.

I looked into it a bit and, likely naively, attempted to add cookie support in OkHttpClientProvider.java by adding:

CookieManager cookieManager = new CookieManager();
cookieManager.setCookiePolicy(CookiePolicy.ACCEPT_ALL);
sClient.setCookieHandler(cookieManager);

Didn't work, but maybe I was on the right track and someone can run with that.

[mkonicek]

Thanks for trying @dizlexik. I agree this is quite high-pri, hopefully we can find bandwidth to fix it soon or someone can send a PR.