cordova-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grant Patterson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CB-10728) Set-Cookie is ignored in WKWebViewEngine
Date Thu, 22 Jun 2017 00:30:00 GMT

    [ 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-unsubscribe@cordova.apache.org
For additional commands, e-mail: issues-help@cordova.apache.org


Mime
View raw message