fetch in companion app do not set login coockies on Android, but dose in the simulator

[hjochman]

Hi,

i have a Iconic and an Android 6.0.1 Backberry PRIV. I wrote some test code for a prove of concept to login to my IBM Domino server. For that I need to send a post request with the login data. The server sends back a cookie if the login was successful. This cookie needs to be send with all future request.

The test code is working fine in the Simulator, but not the Android / Ionic. In the server log I can see that the login was successful for both, but from Android / Ionic all future requests are missing the session cookie. For the Simulator all following request have the session cookie set.

Is that a known bug or do I did something wrong?

/*
 * Entry point for the companion app
 */
const JSON_HEADERS = new Headers({
  'Content-Type': 'application/json'
});

console.log("Companion code started");

doLogin("Hanspeter Jochmann", 'xxx');


function getData() {
  fetch("http://10.10.11.254/mail/hjochman.nsf/rssCal?readviewentries&outputformat=JSON", {
    method: "GET",
    credentials: 'include'
  })
  .then(function(result) {
    console.log("B1");
    console.log(result.status);
    console.log(result.headers.get('Content-Type'));
    return result.text();
  })
  .then(function(data) {
    console.log("B2");
    console.log(`Data: ${data} `);
  })
}     

      
function doLogin(loginUsername, loginPassword) {
  console.log("U:" + loginUsername + " P:" + loginPassword);
  var loginRedirectTo = "http://10.10.11.254/names.nsf/$users?readviewentries&outputformat=JSON";
  var poststring = "Username=" + encodeURI(loginUsername) + "&password=" + encodeURI(loginPassword) + "&RedirectTo=" + encodeURIComponent(loginRedirectTo); 

  var url = "http://10.10.11.254/names.nsf?login";
  console.log(poststring);
  
  fetch(url, {
    method: 'post',
    headers: {
      "Content-type": "application/x-www-form-urlencoded; charset=UTF-8"
    },
    credentials: 'include',
    body: poststring
  })
  .then(function(result) {
    console.log("A1");
    console.log(result.status);
    console.log(result.headers.get('Content-Type'));
    return result.text();
  })
  .then((result) => {
    console.log("A2");
    console.log(`test ${result}`);
    //Login success. Now get the data
    getData();
    
   }).catch(function(err) {
    console.log(`-- Error -- ${err.message}`);
    console.log(`${err}`);
    console.log(`${err.stack}`);
   });
}

[hjochman]

As addition here you see the requests in the web server log:

The 10.10.11.80 is the Simulator and the 10.10.11.71 is my Ionic.

[JonFitbit]

It's quite probable that cookies aren't stored. Perhaps you read them from the initial response and persist them, then construct your own header with the cookie values?

https://developer.mozilla.org/en-US/docs/Web/API/Headers

[hjochman]

Hi Jon,

thanks for your feedback, but this is not working. The server sends the cookie back in the 'Set-Cookie' header name. Exactly this  header name is not accessible for security reasons, as this option is used set the cookie in the local browser.

https://developer.mozilla.org/en-US/docs/Glossary/Forbidden_response_header_name

This need to be fixed in the companion app part of the FitBit app. No one will be able to use fetch for a session based login, as the session cookie that is send from the server is not set and can not be accessed in Javascript to do it by yourself 😞

It is also documented in the fetch git hub pages: https://github.com/github/fetch/issues/386

Hanspeter

[hjochman]

Here is the documentation from the fetch git hub side:

https://github.com/github/fetch#receiving-cookies

Receiving cookies

As with XMLHttpRequest, the Set-Cookie response header returned from the server is a forbidden header name and therefore can't be programmatically read with response.headers.get(). Instead, it's the browser's responsibility to handle new cookies being set (if applicable to the current URL). Unless they are HTTP-only, new cookies will be available through document.cookie.

[JonFitbit]

Seems it's disabled by default in Webviews. https://developer.android.com/reference/android/webkit/CookieManager#setAcceptThirdPartyCookies(andr...)

[hjochman]

Hi Jon,

what do you want to say with that?

My expectation is that you need to add the flag to use cookies in you call to the Webview object inside the FitBit app?

Hanspeter

[hjochman]

Hi Jon,

any time frame when this can be fixed in the Adroid companion app code?

It makes no sense to go on with my project without knowing it will be fixed and abe to test it on the watch itself.

Hanspeter

[hjochman]

Hi, any news how or when the problem will be fixed?

Hanspeter

[hjochman]

Hi Moderators,

any news about the problem?

Hanspeter

[JonFitbit]

Unfortunately, I don't think will change for security reasons.

[hjochman]

What a pity. So we can not use any web service that uses session based authentication.

Hanspeter

P.s.: Where do you see security

---

@JonFitbit wrote:

Unfortunately, I don't think will change for security reasons.

---

problems by accepting cookies? I diden't understand that.

[dsilberg]

Hey @JonFitbit, any progress on this?  It seems like it would be low risk to enable third party cookies and would open the door to developing apps that require this kind of functionality from the API.   This is particularly disheartening as the Simulator doesn't suffer the same problem.  After weeks of development it looks like my app can't actually continue being developed. 😞