4

I am trying to understand CORs a little better as several users of our web app are complaining since they upgraded to iOS 12 they are receiving preflight errors.

The errors from the web inspector

[Error] Preflight response is not successful
[Error] Fetch API cannot load https://www.api.com due to access control checks.
[Error] Failed to load resource: Preflight response is not successful (v4, line 0)

The client app is a React app with Apollo. It calls a server over HTTPS with Apache HTTPD and Express JS.

Everything works fine on all other browsers, this is isolated to iOS 12.

Whats weird is when I look through the HTTPD access logs, I can't see any preflight calls. When I try hit the server directly (on iOS 12), I see both the preflight OPTIONS request and POST in the logs. But when calling the server through the web app, the CORs preflight fails.

In the express app, I also logged out all requests, and it doesn't appear there either.

In HTTPD I have the settings of 

Header set Access-Control-Allow-Origin "*"
Header set Access-Control-Allow-Methods "PUT, GET, POST, DELETE, OPTIONS

In express I have the same thing.

Any ideas?!

dmo
  • 5,102
  • 3
  • 25
  • 28
  • What’s the exact error the browser reports in the devtools console when the failures occur? – sideshowbarker Sep 20 '18 at 22:37
  • @sideshowbarker I added it into the question. cheers – dmo Sep 20 '18 at 23:12
  • OK, so the next thing you probably want to do is to check the request and response with web inspector. Open the Network tab and reload, the click on the `https://www.api.com` OPTIONS request. Check to see what are the exact values of the Access-Control-Request-Method and Access-Control-Request-Headers request headers, and then check the response to see what the HTTP response code is, and the exact values of the Access-Control-Allow-Methods and Access-Control-Allow-Headers response headers, and how those compare to the request headers. – sideshowbarker Sep 20 '18 at 23:21
  • In your frontend code for the request, are you setting the Accept, Accept-Language, or Content-Language headers? – sideshowbarker Sep 20 '18 at 23:26
  • hmm, you know what is weird, there is no method assigned to the request. – dmo Sep 20 '18 at 23:42
  • this is a screen shot of the request from iOS 12 using remote inspector https://imgur.com/a/ZoVrFh2 – dmo Sep 20 '18 at 23:43
  • compared to this from the desktop https://imgur.com/a/tGx7gX7 – dmo Sep 20 '18 at 23:48
  • 1
    this looks like it is more a bug with iOS - I've created a bug with them https://bugreport.apple.com/web/?problemID=44621834 – dmo Sep 21 '18 at 16:23
  • hmm I guess the bug’s not public — when I try that link, I get *“We're sorry, something went wrong. This bug does not exist or you do not have access.”* Anyway, if you get a response to the bug report, please update the question here. – sideshowbarker Sep 21 '18 at 23:21
  • @dmo mind adding your apple bug report to http://www.openradar.me/44621834 ? – Tim Lewis Nov 01 '18 at 01:54
  • 12.1 fixed the issue – dmo Nov 05 '18 at 14:17

4 Answers4

13

It's a bug in iOSv12, but it's already fixed in iOSv12.1 beta (16B5059d), assuming the current beta code makes it into production.

The problem is that iOSv12 WebKit preflight OPTIONS calls don't leave the device. I've run WireShark and the iOSv12 simulator to confirm this.

Nimantha
  • 6,405
  • 6
  • 28
  • 69
S. Met
  • 146
  • 1
  • 3
  • The Ionic community discovered it first with the iOS v12 beta, but according to this post v12 beta 2 fixed the issue: https://stackoverflow.com/questions/50707146/ios-v12-https-requests-errors I don't know what happened between beta 2 and v12 and I'm surprised the other stackoverflow question wasn't reopened. – S. Met Sep 21 '18 at 16:28
  • If that is the same, thats a huge regression. Still surprised more people rant running into it. – dmo Sep 21 '18 at 19:49
  • 1
    Thanks for posting the info here. It seems the resolved WebKit bug for this is https://bugs.webkit.org/show_bug.cgi?id=188355. And the changeset for the fix is https://trac.webkit.org/changeset/234626/webkit – sideshowbarker Sep 21 '18 at 23:35
  • I didn't reopened https://stackoverflow.com/questions/50707146/ios-v12-https-requests-errors?noredirect=1#comment91847698_50707146 because I didn't face the problem with the final version of iOS12. I have installed XCode 10 and tried my app with a simulated device, as I did in June, and didn't ran on the problem – David Dal Busco Sep 23 '18 at 05:58
  • As a follow-up, iOS 12.1 has been released and I can confirm that CORS is working as expected. @dmo has your issue also been resolved? – S. Met Oct 31 '18 at 12:39
  • I just updated to iOS 12.1 and can confirm that I am still having this issue - I don't see the preflight OPTIONS network request in the Safari Web Inspector. – Tim Lewis Nov 01 '18 at 01:48
  • I'm still suffering from the same issue. – dmo Nov 01 '18 at 12:13
  • Confirmed that I was able to resolve my issue and that it works in iOS v12.1. Digging deeper, found that it was also broken in Safari desktop, and that my underlying issue was that there was a 302 location change which Firefox desktop and Chrome desktop would use for the CORS OPTIONS request. Directly calling the final location rather than letting it follow the 302 resolved the issue for me. – Tim Lewis Nov 01 '18 at 14:56
  • I faced the same issue. On updating the iOS to the latest version, its resolved itself. – yokks Jan 16 '19 at 10:14
4

If it says Header not allowed in "Access-Control-Allow-Headers", You can fix it by adding the specific Header from the server side, where you send "Access-Control-Allow-Headers". because wildcard is not working i.e “Access-Control-Allow-Headers”: “*"

It should be “Access-Control-Allow-Headers”: “*, Accept, Content-Type, Content-Length, Accept-Encoding, CUSTOM-ALLOWED-HEADER”

VeeRAdroit
  • 41
  • 1
  • 3
1

For anyone running into this issue, the problem is that iOS12 does not like <add name="Access-Control-Allow-Headers" value="*" /> when you have any custom headers. This was fixed in a BETA that never seemed to make it into an official release.

The solution is to specify each custom header individually, for example: <add name="Access-Control-Allow-Headers" value="*,customheader1,customheader2" />

Wesley Coetzee
  • 4,768
  • 3
  • 27
  • 45
-3

If u got error in ionic, remove this plugin "cordova-plugin-ionic-webview"

AKSHAT JAIN
  • 9
  • 1