breautek commented on issue #1564: URL: https://github.com/apache/cordova-ios/issues/1564#issuecomment-3366626428
First things first, I believe this is likely already solved if you can enable URL schemes and use the file plugin. > Is this approach technically feasible given the current CDVWKWebViewEngine implementation? Yes, in fact the WKURLSchemeHandler is the recommended path, though I believe iOS still uses `file://` protocol by default primarily to avoid introducing a breaking change (I believe the feature was introduced as part of a minor upgrade at the time, iirc). Loading your web app over a scheme handlers avoids a lot of problems relating to CORS (Cross Origin Resource Sharing) and other browser features that are locked behind a "secure" context. > Are there security concerns with allowing scheme handler to access tmp/cache/documents directories? Not that I'm aware of. This should already be possible with the file plugin. If you can obtain the `FileEntry`, you can call `.toURL()` to get a DOM-usable URL where content is fetched over the scheme handler. It's DOM-usable in the sense that you can use the given URL directly in the DOM (e.g. image tags). The app still lives in a filesystem sandbox. The scheme handler is only invokable by that specific instance of the webview, so no other app can make use of it, in short of your app introducing a Remote Code Execution vulnerability by allowing untrusted code to execute within the context of your app. > Has anyone already tried extending the scheme handler for this purpose? Cordova plugins does expose a hook, (See https://github.com/apache/cordova-ios/blob/master/CordovaLib/include/Cordova/CDVPlugin.h#L196) but I'm not sure how useful that is. I honestly thought the File plugin made use of it, but upon reviewing the code it doesn't seem like it. Maybe the core platform might just handle the fetching in generic fashion, or maybe I'm just simply wrong and the file plugin doesn't handle routing to cache or tmp directories... (I'm more familiar with the android implementation than iOS). All of this does depend on enabling URL schemes however, like dpogue pointed out. And doing so does change the document origin like you have pointed out. You can't mix and match URL schemes with `file://` as that will trigger cross origin sharing. On the migration issue... I don't know if any of this has changed, but it was possible to migrate storage containers from UIWebView, to WKWebView, or WKWebView from one origin to another. I don't know if each storage mechanism uses the same thing behind the scenes, but local storage was powered by a SQLite database of a given name, found in a particular folder within your app's data directory. Cordova however takes a "hands-off" approach on data migration and if migrating data is important for your app, then it is your responsibility to handle it. Back when I did it for my own apps, I use https://github.com/totalpave/cordova-plugin-migrate-localstorage/blob/master/src/ios/MigrateLocalStorage.m. The plugin was forked for my own use cases but you can definitely learn about where the files are located and how they should be named. They follow a name pattern of `<scheme>_<hostname>_0`. On the `file://` protocol there is no hostname, the file will be named `file__0`. If you wanted to use `app://localhost`, then the file just needs to be renamed to `app_localhost_0`. Now I did my migration from `UIWebView` -> `WKWebView` around iOS 11 time, so I don't know if anything has changed since iOS 11. I assume they still use SQLite databases. The plugin also only handles local storage, but I think the stuff like IndexedDB and cookies are use SQLite databases probably following the same file name format, just in their own respective directories if I recall correctly. Apple has been making additional restrictions since the enforcement of `WKWebView` regarding `file://` resources, and the solution is typically moving to the scheme handlers. So I think at some point migration is inevitable if you truly require retaining web storage data. And if you're in that situation, then I would strongly consider a migration path that moves your web storage data to a location that is independent of the webview itself. I was in the same boat when I tackled this issue and I ended up migrating to an SQLite database instead so that my data is decoupled from the webview implementation, or even the document origin, or even Cordova for that matter. -- 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]
