Failed to register a ServiceWorker with Cordova 10

[nonameShijian]

Failed to register a ServiceWorker with Cordova 10

[breautek]

I used Cordova version 10.0 to create an offline web game, which provides the WebViewAssetLoader class to access local web pages using HTTPS URLs.
But for the convenience of users to replace files, I want this webpage to display files stored in the external directory of the phone. The directory address is equivalent to 'cordova.file.externalApplicationStorageDirectory', so I made some modifications to the source code of CordovaLib.

This is something I don't think is tested but does service workers work as expected while using internal storage (e.g. if you place your service worker in your www folder)?

I wouldn't expect external storage to work and there are security implications in launching scripts from external storage. Your scripts should be part of your android bundle.

While within the Android OS, android's permission model can restrict applications from accessing or modifying app-specific files on external storage, but the external storage could be on a removable medium and if that storage medium is inserted into another device, say a PC, the file contents of app-specific external files could be manipulated. Therefore applications should treat scripts on external storage as untrusted and unsafe code.

[nonameShijian]

I used Cordova version 10.0 to create an offline web game, which provides the WebViewAssetLoader class to access local web pages using HTTPS URLs.
But for the convenience of users to replace files, I want this webpage to display files stored in the external directory of the phone. The directory address is equivalent to 'cordova.file.externalApplicationStorageDirectory', so I made some modifications to the source code of CordovaLib.

This is something I don't think is tested but does service workers work as expected while using internal storage (e.g. if you place your service worker in your www folder)?

I wouldn't expect external storage to work and there are security implications in launching scripts from external storage. Your scripts should be part of your android bundle.

While within the Android OS, android's permission model can restrict applications from accessing or modifying app-specific files on external storage, but the external storage could be on a removable medium and if that storage medium is inserted into another device, say a PC, the file contents of app-specific external files could be manipulated. Therefore applications should treat scripts on external storage as untrusted and unsafe code.

Just now, I placed 'service worker. js' in the' asset/www 'directory and called the same interface, but still prompted registration failure.

I know that storing startup scripts from external sources does pose security risks, but the web framework used in the game has been in place for a long time and is difficult to modify. The purpose of opening extension interfaces in the game was to allow players to easily modify source code files to achieve the desired effect, and players also have a clear understanding of what modifying source files represents.

[breautek]

Ok thank you, that confirms that it still doesn't work "out of the box".

Glanceful reading, I'm guessing it's because the native needs to handle service worker registration using ServiceWorkerClient[ServiceWorkerController], (https://developer.android.com/reference/android/webkit/ServiceWorkerController), and ServiceWorkerWebSettings.

Cordova doesn't currently do this. The good news is the above classes were added in API 24, which fits within our minimum API level, so if a PR can be crafted and tested then we could potentially roll it into our 13.x release.

However, to re-iterate the service worker registration should probably be in the origin and context of webview asset loader (e.g. https://localhost / internal storage). In fact, MDN states that service workers must be ran in a secure context, thus it needs to go through the webview asset loader and the asset loader must be configured to use the https protocol. Even if the security implications are ignored, there might be technical limitations in registrating the service worker from external storage.

[nonameShijian]

Ok thank you, that confirms that it still doesn't work "out of the box".

Glanceful reading, I'm guessing it's because the native needs to handle service worker registration using ServiceWorkerClient[ServiceWorkerController], (https://developer.android.com/reference/android/webkit/ServiceWorkerController), and ServiceWorkerWebSettings.

Cordova doesn't currently do this. The good news is the above classes were added in API 24, which fits within our minimum API level, so if a PR can be crafted and tested then we could potentially roll it into our 13.x release.

However, to re-iterate the service worker registration should probably be in the origin and context of webview asset loader (e.g. https://localhost / internal storage). In fact, MDN states that service workers must be ran in a secure context, thus it needs to go through the webview asset loader and the asset loader must be configured to use the https protocol. Even if the security implications are ignored, there might be technical limitations in registrating the service worker from external storage.

Thank you for your help. Before that, I had not heard of the ServiceWorkerClient class. I'm going to test if it's usable now. In addition, my game project also needs to be compatible with old platform phones. Previously, I used Cordova 8 and Crosswalk. I plan to extract the code from Cordova 10 about WebviewAssetLoader settings and test it again

[nonameShijian]

Ok thank you, that confirms that it still doesn't work "out of the box".

Glanceful reading, I'm guessing it's because the native needs to handle service worker registration using ServiceWorkerClient[ServiceWorkerController], (https://developer.android.com/reference/android/webkit/ServiceWorkerController), and ServiceWorkerWebSettings.

Cordova doesn't currently do this. The good news is the above classes were added in API 24, which fits within our minimum API level, so if a PR can be crafted and tested then we could potentially roll it into our 13.x release.

However, to re-iterate the service worker registration should probably be in the origin and context of webview asset loader (e.g. https://localhost / internal storage). In fact, MDN states that service workers must be ran in a secure context, thus it needs to go through the webview asset loader and the asset loader must be configured to use the https protocol. Even if the security implications are ignored, there might be technical limitations in registrating the service worker from external storage.

I used 'ServiceWorkerController' in the construction method of the 'SystemWebViewClient. java' file, and then 'ServiceWorker' was successfully registered. Thank you again for your help.

this.assetLoader = assetLoaderBuilder.build();

ServiceWorkerController swController = ServiceWorkerController.getInstance();
swController.setServiceWorkerClient(new ServiceWorkerClient() {
    // I don't know how to reuse this variable, so I wrote it twice
    private final WebViewAssetLoader assetLoader = assetLoaderBuilder.build();
    @Override
    public WebResourceResponse shouldInterceptRequest(WebResourceRequest request) {
        // Capture request here and generate response or allow pass-through
        return assetLoader.shouldInterceptRequest(request.getUrl());
    }
 });
ServiceWorkerWebSettings serviceWorkerWebSettings = swController.getServiceWorkerWebSettings();
serviceWorkerWebSettings.setAllowContentAccess(true);
serviceWorkerWebSettings.setAllowFileAccess(true);