You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cordova.apache.org by "Nikhil Khandelwal (JIRA)" <ji...@apache.org> on 2016/02/29 18:36:18 UTC

[jira] [Updated] (CB-10728) Set-Cookie is ignored in WKWebViewEngine

     [ https://issues.apache.org/jira/browse/CB-10728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nikhil Khandelwal updated CB-10728:
-----------------------------------
    Labels: iOS triaged  (was: )

> Set-Cookie is ignored in WKWebViewEngine
> ----------------------------------------
>
>                 Key: CB-10728
>                 URL: https://issues.apache.org/jira/browse/CB-10728
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: Plugin WKWebViewEngine
>         Environment: Cordova 5.4.0, Cordova-iOS 4.0.1, iOS 9.2.1
>            Reporter: Sverre W
>              Labels: iOS, triaged
>
> I'm trying to upgrade a cordova-ios 4.0.1 app, fully functioning with the old UIWebView, to use cordova-plugin-wkwebview-engine 1.0.2.
> The app does AJAX calls via jQuery, something like this:
> {code:javascript}
> $.ajax({
> 	crossDomain: true,
> 	xhrFields: {withCredentials: true},
> 	url: 'https://server.com/login',
> 	foo: "bar"
> });
> {code}
> After login, the server returns a set-cookie with an authorization token. This cookie is not included in subsequent requests when using WKWebView. It's simply ignored. I've tried multiple CORS configurations on the server, as liberal as possible, with no luck.
> Here are the 3 key requests (I'm omitting unrelated headers like {{Accept}}, {{User-Agent}}:
> *Pre-flight OPTIONS*
> The webview sends an OPTIONS to the login URL with the headers
> * {{Origin: null}}
> * {{Access-Control-Request-Method: POST}}
> * {{Access-Control-Request-Headers: accept, origin, content-type}}
> The server responds with 200 OK and the headers
> * {{Access-Control-Allow-Origin: null}}
> * {{Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS}}
> * {{Access-Control-Allow-Headers: accept, origin, content-type}}
> * {{Access-Control-Allow-Credentials: true}}
> *Login POST*
> Now the webview sends the actual login request, with the header
> * {{Origin: null}}
> The server responds with 200 OK and the headers
> * {{Access-Control-Allow-Origin: null}}
> * {{Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS}}
> * {{Access-Control-Allow-Headers: accept, origin, content-type}}
> * {{Access-Control-Allow-Credentials: true}}
> * {{Set-Cookie: token=abc123; path=/; expires=Fri, 29-Apr-2017 12:49:06 GMT; HttpOnly}}
> *Authorized GET*
> After login the application believes it's logged in, and tries to access a restricted resource. However the only headers sent are {{Accept}}, {{User-Agent}} and {{Origin}}. No {{Cookie}}.
> ----
> Google returns vaguely similar issues around WKWebView and cookies, some of them from the Telerik plugin, but I see no concrete evidence that anyone has gotten this kind of auth flow to work. Even though it does in UIWebView. Is it simply not supported? Am I missing some obscure CORS detail? Either way, maybe it should be documented somewhere.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@cordova.apache.org
For additional commands, e-mail: issues-help@cordova.apache.org