vmware / captive-web-view Goto Github PK

The Captive Web View library doesn't have an explicit version number but it should.

So far, the library for Android has a version in the Maven project object model (POM). See:
https://github.com/vmware/captive-web-view/blob/main/forAndroid/captivewebview/build.gradle#L53
It's a little bit buried.

The library for Apple doesn't seem to declare a version. It isn't clear to Jim how a Swift Package should declare its version number.

Is your feature request related to a problem? Please describe.

The DefaultViewController response() must return Dictionary<String, Any> which means that users of the interface must render responses into that structure.

Describe the solution you'd like

There should be a way to pass any Encodable object as a response. The Captive Web View library could then encode using the built-in JSONEncoder and return it to the JavaScript layer.

Describe alternatives you've considered

No response

Additional context

No response

The CaptiveWebView WebResource findFile method isn't necessarily breadth first. This means that a file lower down the hierarchy with the same name as a file higher up the hierarchy might get found first.
For example:

+---WebResources/
    |
    +---named.html
    |
    +---lower/
        |
        +---named.html

The WebResources/lower/named.html path might be found before the WebResources/named.html path.

This is counter-intuitive and should be fixed.

Diagnostic messages sent to the unified logging system for iOS aren't always accessible, for example in a custom keyboard extension. This problem is an issue for the Dasher Version Six custom keyboard project, which is built on Captive Web View.

See: https://github.com/dasher-project/dasher-captivewebview/

Describe the bug

On Android and iOS the keyboard should open when the focus command is sent from the JavaScript layer to the native layer.

Reproduction steps

See

Expected behavior

On Android and iOS the keyboard should open when the focus command is sent from the JavaScript layer to the native layer.

Additional context

Maybe all that can be done is to upgrade from a comment in code to a documented known issue.

References for iOS and macOS are here and here.

• https://developer.apple.com/documentation/uikit/uiresponder/1621113-becomefirstresponder
• https://developer.apple.com/documentation/appkit/nsresponder/1526750-becomefirstresponder

Maybe add an automated test for Android and other platforms where it works.

The Gradle Wrapper for the Android project should be under revision control. See https://docs.gradle.org/current/userguide/gradle_wrapper.html#sec:adding_wrapper

This means adding the following files.

• captive-web-view/forAndroid/gradle/wrapper/gradle-wrapper.jar
• captive-web-view/forAndroid/gradle/wrapper/gradle-wrapper.properties
• captive-web-view/forAndroid/gradlew
• captive-web-view/forAndroid/gradlew.bat

Do a Gradle version and plugin update at the same time.

I'd like to use Captive Web View for Android as a sub-module under my Android project, instead of by building a local Maven repository.
That doesn't work because, at least, the library web resource assets are included from a directory that is specified in terms of the rootDir. The rootDir is different if the library is included as a sub-module. The specification is near here:
https://github.com/vmware/captive-web-view/blob/main/forAndroid/captivewebview/build.gradle#L19

The Skeleton and MacSkeleton app projects are still using the issue4 branch for Swift Package Manager (SPM). They should switch to the main branch, now that the SPM business is merged to main.

Is your feature request related to a problem? Please describe.

The CaptiveCrypto sample app for Android doesn't support keys in Android StrongBox and capabilities related to StrongBox.

Describe the solution you'd like

Change the generateStoredKeyNamed() and generateStoredKeyPairNamed() functions to create StrongBox keys if the current device supports that, or make that an option for the user.
Add the relevant system features, or all system features, to the capabilities JSON dump.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

The builtInFetch implementations for Android and iOS don't return detailed errors.

Describe the solution you'd like

The builtInFetch implementations for Android and iOS should return a structure like this in the case of an error.

{
    fetchError: {
        statusCode: 404, statusMessage: "Not found", ...
    }
    fetchedRaw: "Whatever the sever returned or null if nothing"
}

For comparison, this is the structure returned if the fetch is OK.

{
    fetched: { /* fetched JSON goes here. */ }
}

Also, the builtInFetch implementations for Android and iOS should accept an optional callback parameter that receives the native error object.

builtInFetch for Android is here.

builtInFetch for iOS is here.

Fetch error structure from Python harness are here.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

A proprietary app I was working on utilises class private properties and methods. This is the JS syntax.

class Blib {
    #privateProperty;
    #privateMethod() {}
    // ...
}

Turns out class private methods aren't supported by version 74 of Android WebView, which can still be encountered on some emulators. I guess it's because emulators typically don't register to a Google account and therefore don't pick up Play Store updates to the system WebView.

Describe the solution you'd like

Have a number of small JS module files in the library resources each of which would confirm availability of a language feature, for example class private methods. The library would attempt to import each module and then report which features are available.

Also the JS layer should report the user agent to the native layer somehow. User agent can be obtained like this.

window.navigator.userAgent

Describe alternatives you've considered

No response

Additional context

No response

Captive Web View for iOS and macOS should have a Swift Package Manager (SPM) package for distribution.

Is your feature request related to a problem? Please describe.

Captive Web View should facilitate correct inspectability settings in web views. Inspectability is what allows, for example, Chrome and Safari developer tools to be attached to a web view in an app. The developer tools facilitate debugging HTML, CSS, and JavaScript running in the web view.
In general, web views should be inspectable during development, and shouldn't be inspectable in production.

Describe the solution you'd like

The operating systems in scope of Captive Web View have different native mechanisms for setting inspectability. These mechanisms are extended from time to time. See these links for example.

• https://developer.android.com/reference/android/webkit/WebView#setWebContentsDebuggingEnabled(boolean)
• https://webkit.org/blog/13936/enabling-the-inspection-of-web-content-in-apps/

Captive Web View should

• set a sensible default inspectability.
• offer a programming interface by which the app can check the current inspectability.
• offer a programming interface by which the app can set inspectability, at run time if possible or at build time otherwise.

Describe alternatives you've considered

The web view inspectability mechanisms for iOS were extended in version 16. Code like this must be added to an app to make its web view inspectable.

        if #available(iOS 16.4, *) {
            self.webView.isInspectable = true
        }

Note that all the other existing factors that affect web view inspectability for iOS still apply. For example, Web Inspector must still be switched on in the device Safari settings as discussed here. https://developer.apple.com/documentation/safari-developer-tools/inspecting-ios

Additional context

No response

Is your feature request related to a problem? Please describe.

Suppose I have an enum class for commands and keys that can be sent between the JavaScript and Kotlin layers. An enum class is a stringless approach for that.
There are some common commands and keys that are implemented in the Captive Web View library. It’d be nice to have an enum subclass in the app, with additional commands that are specific to the app. However Kotlin doesn’t support enum subclasses.

Describe the solution you'd like

There should be a solution based on Kotlin @IntDef so that subclassing can be utilised.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

The builtInFetch implementations for Android and iOS don't return the peer certificate of the HTTP server.

Describe the solution you'd like

The builtInFetch implementations for Android and iOS should return a representation of the server peer certificate in a structure like the Python harness does.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

The native code in the CaptiveCrypto sample app for Android is all in one class and all in one file.
https://github.com/vmware/captive-web-view/blob/main/forAndroid/CaptiveCrypto/src/main/java/com/example/captivecrypto/StoredKey.kt

Describe the solution you'd like

The code should be in several files, perhaps in a package instead of a single class.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

The native code in the CaptiveCrypto sample app for iOS is all in one big file.
https://github.com/vmware/captive-web-view/blob/main/forApple/CaptiveCrypto/CaptiveCrypto/StoredKey.swift

Describe the solution you'd like

The code should be in several smaller files, perhaps making use of a Swift enumeration as a namespace.

This type of solution was already implemented for #28 which was the same issue in the code for Android.

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

The CaptiveCrypto sample app for Android generates key pairs that don't support hardware attestation.

Hardware attestation is discussed here and here for example.

• https://developer.android.com/training/articles/security-key-attestation
• https://developer.android.com/reference/kotlin/android/security/keystore/KeyGenParameterSpec.Builder#setattestationchallenge

Describe the solution you'd like

Change the generateStoredKeyPairNamed() function to generate key pairs that support hardware attestation.
Change the KeyStore.describeKeyNamed() function and EntryDescription data class to include a summary of the chain of trust, if any.

Describe alternatives you've considered

No response

Additional context

No response

Describe the bug

Looks like the following line should be conditionally excluded for macOS
public extension CaptiveWebView.DefaultViewController {

It's because the DefaultViewController member isn't there for macOS. Captive Web View support for macOS supports web views but doesn't support higher level user interface elements like view controllers.

Reproduction steps

1. Try to build the MacSkeleton app.
2. Build fails with an error like this.
   captive-web-view/Sources/CaptiveWebView/DefaultViewController+Fetch.swift:47:33 'DefaultViewController' is not a member type of struct 'CaptiveWebView.CaptiveWebView'

Expected behavior

Build should succeed.

Additional context

No response

Describe the bug

The library code uses a stringless approach to reduce the incidence of error in command names and key names. For example, see these locations.

• captive-web-view/forAndroid/captivewebview/src/main/java/com/example/captivewebview/DefaultActivityMixIn.kt

  Line 50 in ac11fad

  private enum class Command {

• captive-web-view/forAndroid/captivewebview/src/main/java/com/example/captivewebview/DefaultActivityMixIn.kt

  Line 62 in ac11fad

  enum class KEY {

However, the readme files still use strings, for example for the "ready" command name.

Reproduction steps

1. Look in the library code.
2. Look at the readme file for Android or for Apple.

Expected behavior

The best practice approach, stringless in this case, should be documented and used consistently.

Additional context

No response

Is your feature request related to a problem? Please describe.

Captive Web View for iOS at least should instantiate transparent web views, by default or as an option.

Describe the solution you'd like

See this SO answer for a discussion.
https://stackoverflow.com/questions/3646930/how-to-make-a-transparent-uiwebview#3935033

Describe alternatives you've considered

No response

Additional context

No response

Is your feature request related to a problem? Please describe.

The project hasn't been built with Android Studio Flamingo yet, nor updated to the latest Gradle and Android libraries.

Describe the solution you'd like

The project should be built with an Android Studio Flamingo version to confirm compatibility.
The project build should be updated to the current Gradle version.
The project dependencies should be upgraded to 1.7 Webkit, the latest appcompat library versions, and so on.
The targetSdk and compileSdk properties should be updated to 33, which represent Android 13.
Support for some early Android versions can be withdrawn. At time of writing, minSdk is 26. It could be increased to 29, which represents Android 10.

Describe alternatives you've considered

No response

Additional context

AS Flamingo is the latest version of AS at time of writing.

Is your feature request related to a problem? Please describe.

The native code in the CaptiveCrypto sample app for Android has a cipher specification selector, here.

Describe the solution you'd like

The selector should specify a cipher that is based on more of the Key capabilities than just the algorithm.

Specification code could do this.

1. Instantiate a suitable KeyFactory or SecretKeyFactory for the Key.
2. Generate a KeyInfo object.
3. Inspect the KeyInfo object to discover the detailed capabilities of the Key.
4. Specify a cipher based on the KeyInfo for the supported algorithm, block modes, and padding.

Similar steps should be taken to specify the OAEPParameterSpec object used in RSA encryption and decryption. At least the message digest specification should be based on Key capabilities, instead of being hard-coded. Code is here and here.

• captive-web-view/forAndroid/CaptiveCrypto/src/main/java/com/example/captivecrypto/StoredKey.kt

  Line 426 in a5ae78a

  KeyProperties.KEY_ALGORITHM_RSA -> OAEPParameterSpec(

• captive-web-view/forAndroid/CaptiveCrypto/src/main/java/com/example/captivecrypto/StoredKey.kt

  Line 490 in a5ae78a

  KeyProperties.KEY_ALGORITHM_RSA -> OAEPParameterSpec(

Describe alternatives you've considered

No response

Additional context

No response

Describe the bug

The code uses ECB mode, which is generally deprecated.

Reproduction steps

Look at the code here and here for example.

• captive-web-view/forAndroid/CaptiveCrypto/src/main/java/com/example/captivecrypto/StoredKey.kt

  Line 353 in e831b0e

  KeyProperties.KEY_ALGORITHM_RSA -> "RSA/ECB/OAEPPadding"

• captive-web-view/forAndroid/CaptiveCrypto/src/main/java/com/example/captivecrypto/StoredKey.kt

  Line 330 in e831b0e

  setBlockModes(KeyProperties.BLOCK_MODE_ECB)

Expected behavior

It's expected that ECB isn't used.

Additional context

No response