[
https://issues.apache.org/jira/browse/CB-10728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058521#comment-16058521
]
Grant Patterson commented on CB-10728:
--------------------------------------
I'm having this problem, but a) only with AJAX calls and b) only in iOS
Simulator. I can work around it by setting document.location to my server's
login link, which breaks things (I'm navigating away from the file:// path that
runs my app) but logs in the WKWebView successfully. If I restart the app, the
WKWebView remembers the relevant cookies and is logged in, and I'm back at the
file:// path that runs the app properly.
> 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: cordova-plugin-wkwebview-engine
> 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.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org
