breautek commented on issue #1299: URL: https://github.com/apache/cordova-ios/issues/1299#issuecomment-1475446203
> [Error] Origin app://localhost is not allowed by Access-Control-Allow-Origin. Status code: 200 This indicates that your server is not returning `app://localhost` in it's `Access-Control-Allow-Origin` response. > `<preference name="scheme" value="https" />` This is an invalid configuration for iOS, although it's valid for Android. Android scheme must be either `http` or `https`, whereas iOS can be anything that isn't a "well-known scheme". Apple doesn't explicitly declare what that means, but virtually any standardized protocol is an illegal scheme. This means that you can't have a consistent origin cross-platform, since the two platforms have conflicting requirements. When iOS encounters an illegal scheme, it fallsback to `app`, which is why you're origin becomes `app://localhost` despite the `scheme` being set to `https`. Leaving it as is ok, but just explaining **why** your origin is `app://localhost` instead of `https://localhost`. You haven't told us what you have your `Access-Control-Allow-Origin` to, so for the moment I'm going to assume it's not `app://localhost`... more on this later... On the server side, because you support both Android and iOS also means you need to be flexible and return a different value depending on the `Origin` request header. Any CORS request will have a `Origin` header on the request, which you can pass back as the `Access-Control-Allow-Origin` to make it act as a wildcard. Additionally you could check to see if `Origin` is what you expect, if you like. The `Access-Control-Allow-Origin` only accepts 1 value, but that value can be a `*` for a wildcard. I've had issues with this method on older iOS devices however (pre iOS 10). I haven't actually tested if it works properly on iOS 11+. > You haven't told us what you have your `Access-Control-Allow-Origin` to, so for the moment I'm going to assume it's not `app://localhost`... more on this later... If your `GET` request **is** returning `Access-Control-Allow-Origin` response header with the value of `app://localhost`, then you might be triggering a preflight CORS request, which may happen if certain conditions are met. [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#examples_of_access_control_scenarios) goes into more detail on these conditions. If your request requires a preflight request, then your server must respond to the `OPTIONS` request in addition to the `GET` (or whatever HTTP Method your main API endpoint is) The `OPTIONS` request shall respond with: - Status 204 (OK No Content) - Any `Access-Control` response headers as appropriate. At minimum, `Access-Control-Allow-Origin` is required. `Access-Control-Allow-Headers` may be required if you use custom headers. - Returns `Content-Length` 0 (has no body content). You can test your endpoints to confirm if the server is responding properly with the proper response headers using a non-browser based HTTP client. Personally I use [Postman](https://www.postman.com/) for this. I have a [blog post](https://breautek.com/articles/enabling-cors.html) that goes into much more detail on how to handle CORs, with NGINX config examples, but the general concept should be able to be applied to any webserver technology. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
