breautek commented on issue #1562: URL: https://github.com/apache/cordova-android/issues/1562#issuecomment-1448253574
CORS is a browser technology that cannot be disabled* (More on this later), so there is no configuration on the app side to handle CORS, however the `hostname` and `scheme` preferences will play a part since they dictate the `origin` of your app. On browsers which implements the CORS protocol, every request will send it's origin via the `Origin` request header. Some requests will also send a "preflight" request as an `OPTIONS` method request just before it sends the actual request. The server must respond to both of these requests with the appropriate `Access-Control` headers. At minimum it must provide the `Access-Control-Allow-Origin` response header to both the `OPTIONS` method of the request (if the browser sent one), and the original request along. `Access-Control-Allow-Origin` accepts only a single value, which by spec can be a `*` (wildcard), an `origin` (e.g. https://example.com), or `null` (for `null` origin, which is the origin of filesystem files and some other nuances). In my experience however, `*` wildcard does not work in older iOS devices (I think pre iOS 11, so this detail might not matter). But the server side can do logic to read the `Origin` request header and set it to the response `Access-Control-Allow-Origin` header, which effectively makes it a wildcard. Additionally you could do further logic to only allow expected origins, but don't use it to "secure" your server. Anybody can create an app with any origin. I have a [blog post](https://breautek.com/articles/enabling-cors.html) that goes into much more detail with some NGINX examples. It's tailored for iOS WKWebView, but all the same information still applies to Android webviews as well. The examples are hopefully transferable to whatever backend technology you're using. What matters is that you can set the response headers, and respond to any `OPTIONS` request of your API endpoints. [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) also has a good article on the CORS protocol in general. > CORS is a browser technology that cannot be disabled* (More on this later) I'm not 100% sure on this, but most people have raised issues relating to CORS when they upgraded to cordova-android@10 or otherwise migrated to scheme-based webview, which was introduced in cordova-android@10. So I believe Android WebView only enables CORS on documents that has a `http` / `https` origin, which the scheme-based webview does. If this is the case, then setting the `AndroidInsecureFileModeEnabled` preference to true will revert the webview back to the filesystem-based webview, which should make it behave like cordova-android@9 and earlier. However the webview has been increasingly adding in restrictions that requires a "secure context", e.g. you must be on a `https://` origin document. So using the scheme-based webview (`AndroidInsecureFileModeEnabled = false`) and handling CORS on the server side should be your first choice. Lastly if you do not have access to the server to make the changes, then you have few non-ideal options: 1. Ask your server administrator if they can make the changes 2. Build a proxy server that you do have access to that can implement the CORS protocol, but pass the request onto the real server. 3. Do not use the browser's `XMLHttpRequest`/`fetch` APIs. Instead use a cordova plugin that allows you to use the native HTTP clients, which isn't part of the browser and thus not enforcing CORS. Hopefully this is enough to go on and because this isn't really a bug, I'll be closing the ticket. However if you do have further questions, posting inside the [Discussions](https://github.com/apache/cordova/discussions) board will be an appropriate place for community support. -- 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]
