feat(ios): Added support for https urls access to local files.

[guylando]

Currently if you load a remote https page (on domain xxx.com) on the ios webview then cdvfile://... urls requested from that page for active content such as js and css files are blocked by the mixed content policy.
This PR solves this by allowing access to cdvfile://localhost/bundle/www/cordova.js using the url: https://xxx.com/cdvfile/bundle/www/cordova.js
Since this url is https and from same domain as the remote https page, this works!

Reference:
https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content#Mixed_passivedisplay_content
https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content/How_to_fix_website_with_mixed_content

[syonip]

@guylando I'm having this issue too.
Any progress on this PR?
Do you need help doing the android side? Happy to help

[guylando]

@syonip my changes work well, seems just that this repository is not maintained too much.
android does not require those changes since there is a flag in android webview which disables mixcontent being blocked.

[guylando]

@janpio I think the android tag is wrong since this is an ios modification

[janpio]

Correct, that was a miscategorization. Fixed it.

[janpio]

Restart tests.

[janpio]

Hey @guylando, does xxx.com have any meaning in that URL? The related Android PR uses just https://cdvfile/ which seems like a cleaner design, do you agree?

[janpio]

CI: Please run the tests again.

[janpio]

CI: Once more please.

[guylando]

@janpio cleaner than what? the android side I use is your original implementation so are you asking if his PR is cleaner than your original implementation? all I did in android is allow your original implementation to work in a mixed content environment

[janpio]

My comment contains a link to the PR I referred to - @syonip created a similar PR for Android which uses a slightly different "design" for the special URL.

[janpio]

The more important question to be able to understand and test your PR was this:

Hey @guylando, does xxx.com have any meaning in that URL?

Can xxx.com be anything? Or does it have to be the actual website that is loaded via https:// in the webview for this to work?

If this is true, am I correct that one could also describe this PR as to adding a special cdvfile folder https websites that is intercepted locally and redirected to the file plugin to be able to server local files?

[gwynjudd]

Does this feature work for WKWebView? Please note that WKWebView does not yet support NSURLProtocol (https://stackoverflow.com/questions/24208229/wkwebview-and-nsurlprotocol-not-working). Also, even though there is WKURLSchemeHandler, you cannot register a scheme handler for https.

I have tried this patch in iOS device with WKWebView, and it doesn't appear to work for me. Has it worked for you at all?

[TaDaa]

Same issue -- haven't been able to get this work on WKWebView. From a dev standpoint on IOS this is frustrating (and also due to how inconsistent the implementations are between platforms). Just about every major release the internal mechanism for serving files has changed without what feels like much consideration.

[gwynjudd]

I've gotten access to local files working in WKWebView using a WKURLSchemeHandler but the url schema has to be non http/https (e.g. cdvfile: works).

[TaDaa]

Are you accessing cdvfile: from a "https" site? http should work fine, but https seems to throw [blocked] due to mixed-content (https to non-secure).

[gwynjudd]

I've been using https

[lovelyelfpop]

Has this pr been merged?

[guylando]

@janpio using https://cdvfile will create CORS errors probably. better to use https://xxx.com/cdvfile where xxx.com is the site the browser is viewing and this way there are no CORS problems

[weareu]

This is now also broken on Android Template 10 for cordova as that requires serving via https: cvdfile no longer works. Using a virtual folder is best due to CORS. Changing the hostname is not a good idea. Once this is merged the same thing should happen for Android to standardise.