CORS issues

[ibsus]

When enabling wkwebview, requests to a webserver are from "null" and therefore rejected even with Access-Control-Allow-Origin set to *

[jgw96]

Hello! Thanks for opening am issue with us! Would you mind posting a repo that I can use to reproduce this issue? Also, does a request to the same server work without the plugin (on uiwebview) ?

[ibsus]

Unfortunately it is private source. Will try to recreate and send

On Thursday, August 18, 2016, Justin Willis notifications@github.com wrote:

Hello! Thanks for opening am issue with us! Would you mind posting a repo that I can use to reproduce this issue? Also, does a request to the same server work without the plugin (on uiwebview) ?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/driftyco/cordova-plugin-wkwebview-engine/issues/3#issuecomment-240910906, or mute the thread https://github.com/notifications/unsubscribe-auth/AADMWKJ0rcdVY34FqbNKoA-EHQivaQkCks5qhRLugaJpZM4JoEyM .

[jgw96]

Thanks, much appreciated!

[ghenry22]

I might have a less strict web service that I am connecting to but I have no problems with HTTP requests. If there is something specific that it's useful to check I can try and log more detail on my server to confirm if that's useful

[manucorporat]

@ghenry22

I have no problems with HTTP requests

so HTTPS?

[leonardoalemax]

i`m geting the same error here with the plugin:

looking forward to use it in prod, nice job guys, you are awesome!

[ghenry22]

I'll try HTTPS but won't get time until Monday.

[calendee]

Also seeing the origin null is not allowed by Access-Control-Allow-Origin.

The problem does not exist in the traditional UiWebviuew.

Failed to load resource: Origin null is not allowed by Access-Control-Allow-Origin.
XMLHttpRequest cannot load https://XXXXXXX.com/AuthenticateUser. Origin null is not allowed by Access-Control-Allow-Origin.

[calendee]

Here's a screenshot showing how the OPTIONS pre-flight has an origin of null.

[danbucholtz]

@calendee, can you take a screenshot of the above with UIWebView?

Thanks, Dan

[leonardoalemax]

it`s not the same request from calendeen, but using UIWebView this is my request:

using WKWebView i`m getting the same as him.

[manucorporat]

@calendee is your server crashing?

[calendee]

@manucorporat Nope - no crashing. The server is just returning 500 because the OPTIONS preflight has null in the origin.

FYI: In UiWebView, I don't send OPTIONS preflights; so, I don't get this problem and can't screenshot it for you.

• I guess that's the real question : Why does WkWebView send an OPTIONS preflight while UIWebView does not?

[peterpeterparker]

In my case I definitely have that error result when Access-Control-Allow-Origin isn't set to *

My node JS server define headers like following:

res.header("Access-Control-Allow-Origin", "https://mydomain.com");
res.header("Access-Control-Allow-Credentials", "true");
res.header("Access-Control-Allow-Headers", "Origin, Authorization, Content-Type, Content-Range, Content-Disposition, Content-Description, X-Requested-With, X-ACCESS_TOKEN");
res.header("Access-Control-Allow-Methods", "GET,PUT,POST,DELETE");

Which lead to the error we are speaking about with WkWebView. I tried the experiment to change following line and I didn't faced the error anymore, I was able to log in and use my app and own server services with WkWebView.

res.header("Access-Control-Allow-Origin", "*");

Of course that was only an experiment, because I also use other API that can't make this change and also I'm not really willing to. But in my case, that is the reason for the error "origin null is not allowed by Access-Control-Allow-Origin"

P.S.: I use HTTPS

[mbrookson]

I am seeing this as well. I've installed the WKWebView plugin, but now web requests just don't work because of the Access-Control-Allow-Origin rules which don't matter with UIWebView. The error says Failed to load resource: Origin null is not allowed by Access-Control-Allow-Origin.

I've tried adding

<meta http-equiv="Content-Security-Policy" content="script-src * 'unsafe-eval' 'unsafe-inline'; connect-src * 'unsafe-eval'; object-src *; style-src * 'unsafe-inline'; img-src *">

to index.html but this didn't resolve the issue

[daviddk]

Also seeing this problem, It seems WkWebView is just sending out requests with the 'Origin' header set to null. For UiWebView it was set to 'file://' and didn't give any problems.

[PapyElGringo]

Same here any solution found on your side guys?

[willadamskeane]

I'm having this issue as well.

[VinKamat]

Seeing the same issue. Would love to use this plugin. It's as if the most important aspect of an app making http calls is now not possible. Weird.

Error: XMLHttpRequest cannot load http://myserver.com/api/login. Origin null is not allowed by Access-Control-Allow-Origin.

Any workarounds? solutions?

[danbucholtz]

All - @manucorporat is working on this bug. I believe he's AFK for a week or so. He'll get back to this shortly.

Thanks, Dan

[mbrookson]

That's good news! :)

Bit of a shame to have such a big issue with this straight away which stops many apps from working at all, even after the plugin has had a blog post and is promoted by Ionic. This plugin seems really promising for performance though and looking forward to using it!

[vuhung3990]

i have same issue : Origin null is not allowed by Access-Control-Allow-Origin

[danbucholtz]

@mbrookson,

Yeah, it's a little unfortunate, but that's why we're asking for beta testers now vs releasing it and saying it's good to go 😄. We've now identified a major issue that we need to fix, so that's great. We did test HTTP and didn't have any issues, but it must have been with the way our server was configured. We are all swamped right now getting Ionic V2 ready to go. Hopefully, the plugin will be ready for prime time to correspond with Ionic V2 RC.

Thanks for checking it out everyone, the issues submitted so far have been great!

Thanks, Dan

[lordgreg]

Same issue.

[cvenzin]

Same here

[manucorporat]

I am not in town until September 1st. Are you guys tried debugging this bug server side? I don't think we can change anything in this plugin to fix this issue (I might be wrong).

http://stackoverflow.com/questions/36000757/cordova-ios-error-origin-null-is-not-allowed-by-access-control-allow-origin

[lordgreg]

@manucorporat I'm not getting it. How can this be server-side issue if the REQUEST HEADER is already the one with false header (aka NULL)?

[mbrookson]

I understand that you can configure CORS settings on the server side, but I don't particularly want to do that if possible. Has something changed with the WKWebView which doesn't allow it to work the same as UIWebView because this has never been a problem before?

[peterpeterparker]

@manucorporat yes I did some debugging server side, see my comments.

[danbucholtz]

@peterpeterparker,

I believe Manu meant September 1st. I have updated his post.

Thanks, Dan

[peterpeterparker]

@danbucholtz thx for the feedback. I updated my post too.

[scottopolis]

Thanks for this guys, I'm excited to use it, but I'm also seeing the CORS issue. With the normal webview, I can access an iframe like this:

var iframedoc = document.getElementById('myApp').contentWindow.document; var shareBtns = iframedoc.getElementsByClassName('share');

Attempting this with the wkwebview gives me an error referring to the "null" origin that others have mentioned: [Error] Blocked a frame with origin "null" from accessing a frame with origin "http://mysite.com".

I have tried setting CORS headers on my server, and every whitelist configuration possible in config.xml, it does not help. This issue is definitely related to the wkwebview plugin.

Thanks!

[ErkoKnoll]

@scottopolis same issue here. Trying to access an iframe to call a function in in is being bocked by WKWebView. In the older UIWebView it wasn't a problem.

[cojj90]

We have an application that works perfectly on UIWebView published on appstore. Did the drop-in upgrade as per instruction and it fails with CORS error.

Some note:

• The app fails on the first https call to google (google+ login).
• We are not using iframe.

[AllSeeingEye]

This issue isn't actually an issue, but an "expected" behavior of WKWebView:

https://issues.apache.org/jira/browse/CB-7348

"this is the opposite of what happens in a UIWebView, where a page loaded locally is not restricted to CORS and can do whatever it wants."

So, now both the server and the local app must conform to CORS rules.

[dorgold]

@AllSeeingEye This is not the problem here, there is no problem with confirming to CORS rules, the problem is the now all the requests are sent with a "null" origin. Even if my server allows all origins, "null" origin will just won't work. The webview just needs to send requests with any valid origin (let's say "file://", or anything but "null").

[cvenzin]

This is a bug of the WKWebView engine. Origin null is not a valid header. I don't know of any backend that actually can match an origin of null. Sadly the WKWebView Team thinks this is correct and expected behavior ...

[ErkoKnoll]

Couldn't it be overwritten in JS with document.domain property?

[AllSeeingEye]

@dorgold understood, sorry.

[peterpeterparker]

A couple weeks ago I faced that problem and also noticed, that it was kind of a dead end. That's why I thought, gonna repost here:

that maybe the problem could be solved within the use of a proxy running in the app?

The Ionic team provide an awesome proxy I, maybe we all, use it to debug our app in our local browser (see config ionic.config.json, you know what I mean). Maybe would it be possible to extend this proxy functionality to be allowed to be chipped with our apps?

[adrinavarro]

If I get this right, the CORS header is null and therefore it is impossible to do requests from the app to any outside service via http, even though the access control allow origins is set to wildcard on the server side.

This means that this plugin is useless for any apps that require access to remote data via http to work.

Any updates? We really want to use this plugin, but being unable to do external requests due to the invalid origin, we have our hands tied to the old UIWebView.

[sg1705]

Yep - The plugin is not useful until CORS issue can be fixed. wkwebview is all we got to make apps perform better on iOS. But given the issues with wkwebview and cordova, it is probably not worth the effort to try to make it work.

Heroic effort from @manucorporat and Ionic though.. kudos!

[manucorporat]

@cvenzin well! it is not. "null" is a valid Origin, probably a server bug or bad configuration ( https://tools.ietf.org/html/rfc6454#section-6.2 ), as I said previously. I have been very busy fixing other issues in this plugin and in ionic framework. I will try figure out what is going on with WKWebView and CORS, because it does not make sense that some servers work while other don't.

@adrinavarro no, it is not impossible. That's what I try to explain. Just some server have problems. Others work perfectly.

ping @sg1705

[sg1705]

@manucorporat the problem is not of servers. The problem is that when the app (using wkwebview) makes a request, origin is null. Most services like auth0 and firebase don't allow origin as null (since it is not secure, see issue) and rightly so.

Not sure if we can blame services for rejecting requests from null origin.

[AllSeeingEye]

@manucorporat basically, current wkWebView doesn't correct it's behavior (with respect to "origin") when run from the local device. We need a way to correct or, at least, override this behavior.

[manucorporat]

@AllSeeingEye @sg1705 I see your point! believe me. But, WK is doing the right thing. "Origin: file://" and stuff like that was never a valid Origin. "null" is. And it should be accepted.

C'mon! They accept "*" but not null, because it is less secure?

"Not sure if we can blame services for rejecting requests from null origin"

we could blame the standard instead.

6.2.  ASCII Serialization of an Origin

   The ascii-serialization of an origin is the value returned by the
   following algorithm:

   1.  If the origin is not a scheme/host/port triple, then return the
       string

          null

7.3.  User Agent Requirements

   The user agent MAY include an Origin header field in any HTTP
   request.

   The user agent MUST NOT include more than one Origin header field in
   any HTTP request.

   Whenever a user agent issues an HTTP request from a "privacy-
   sensitive" context, the user agent MUST send the value "null" in the
   Origin header field.

      NOTE: This document does not define the notion of a privacy-
      sensitive context.  Applications that generate HTTP requests can
      designate contexts as privacy-sensitive to impose restrictions on
      how user agents generate Origin header fields.

Please don't get me wrong, I am actively working right now to find a solution. But it is not as easy as saying, "WKWebView is doing the wrong thing, we have to override it"

[sg1705]

@manucorporat , I think you are right here. I saw you posted in auth0 forum. Thanks for looking into this.

[manucorporat]

I want everyone to calm down, we will find a working solution one way or another :) In the meantime I working in a way to bypass CORS completely. So no "Origin" at all!

[danbucholtz]

To be clear, we (the Ionic team) did test this with several HTTP frameworks and web services before shipping. It works in some of the more popular web server libraries, but seemingly not all libs.

What server side frameworks are causing trouble with the origin null? It may be useful to know.

Thanks, Dan

[pieterbeens]

@danbucholtz I'm having trouble with Auth0. Login attempts fail with message "Origin null is not allowed."