01-10-2020 19:01
01-10-2020 19:01
I'm trying to use the fetch API from a companion app to authenticate to a third-party web service. The service is designed for browser-based auth: on success, it returns a 302 redirect response with a Set-Cookie header. I can't figure out how to make this work in the Fitbit interface (mainly testing in the simulator, in case it makes a difference).
If I specify `redirect: "manual"` in the request, I get a response with type `opaqueredirect` and I can't see the Set-Cookie header. I understand why this is needed in a browser context, and in a browser I'd just use `redirect: "follow"`, let the browser process the Set-Cookie header, and then (subject to origin checks) I can read (or just use) the cookie from the browser's cookie store. But it doesn't look like the fitbit companion's implementation of fetch() supports this - if I let it follow the redirect, it looks like the Set-Cookie is simply ignored (it's possible I'm missing something here; it's hard to observe this directly).
Is there any workaround for this? I'd be happy with either a way to observe the headers of a redirect request, or a way for the system to process the Set-Cookie and let me make requests with that Cookie header later. Or as a last resort I could set up a proxy server somewhere and convert redirects into other kinds of responses, but I'd prefer not to do that.
Answered! Go to the Best Answer.
01-14-2020 10:39
01-14-2020 10:39
I don't think this is currently possible due to the webview environment used on the phone. I beleive it's a security restriction that won't be changing.
01-12-2020 08:59
01-12-2020 08:59
> But it doesn't look like the fitbit companion's implementation of fetch() supports this - if I let it follow the redirect, it looks like the Set-Cookie is simply ignored (it's possible I'm missing something here; it's hard to observe this directly).
I was wrong here - the set-cookie is working correctly. My problem is that I was using a non-canonical domain and the redirect changed the domain in addition to setting the cookie (this made the cookie effectively useless since it wasn't set on the canonical domain that needed to read it.
01-13-2020 10:08
01-13-2020 10:08
I spoke too soon - this works on the simulator, but not on the device. I can't seem to make anything involving cookies work on the device (either with implicit browser-style cookie storage or explicitly passing the Cookie header). Is there any way to send HTTP requests from a companion app that include cookies?
01-14-2020 10:39
01-14-2020 10:39
I don't think this is currently possible due to the webview environment used on the phone. I beleive it's a security restriction that won't be changing.
01-19-2020 14:31
01-19-2020 14:31
OK, thanks for confirming. I've written a little proxy server that transforms the request and response so I don't need cookies in the companion app. Not ideal from a security/privacy perspective, but it works.
Consider this a feature request for the simulator to have the same restrictions on cookie usage as the real device.