HTMLViewer: How to detect a Callback/Redirect to a custom URL scheme?

I’m trying to use an Identity Server with the standard oAuth2 / OpenID authentification workflow in a Xojo built application.
What’s going on is basically:

  • use a HTMLViewer to load the Authentification URL
  • the Identity Server will handle the Authentification
  • once successfully authenticated, it will send a Redirect (as a Callback) to a custom URL Scheme (which in this/our case is unfortunately defined by the server, and can’t/won’t be changed)
  • The redirected URL will contain an id_token which is of interest for further Authentification steps
  • The Xojo built application will just need to intercept that id_token in the Redirection/URL… That’s easily possible in HTMLViewer's .CancelLoad or .DocumentComplete Events (depending on the Operating System and Renderer [Native, WebKit])

I have created an example project that simulates that process.
And it’s working just fine and as expected on Windows and Linux.

However… not on macOS :frowning:
It seems to me that HTMLViewer on macOS does not even try to load such an Redirect: oob://testapp/callback#id_token=abcd1234.
The other Operating Systems will either try (so you can intercept .CancelLoad) or show an error page (and you get to see the desired value in .DocumentComplete).

If Xojo’s HTMLViewer on macOS would use WKWebView, it would/could work like this. In order to handle the redirect, you need to implement decidePolicyForNavigationAction in the WebPolicyDelegate of your WKWebView to detect the custom URL scheme and….
But since that’s (not yet) the case - how can this be achieved with Xojo’s current implementation of HTMLViewer?

Where to start looking for a solution? Is the reason that the “old WebView” doesn’t get the (redirected / custom) URL because of App Transport Security (ATS)? Would it be possible to use Declares on the WebView to be able to get the Redirection (even if it’s not going to be performed, which also doesn’t matter - since one only needs to somehow “see” that Redirection URL). Or do I need to somehow setup the application (Info.plist) to “handle to this URL” (so that WebView will try to load it)?

Thanks for your ideas - feel free to play with the example project. I’ll leave the example project and WebService/Test up and running for a little while. I’m curious if someone is able to get the id_token on macOS with “Xojo means” (*).

(*) I think that MBS has a WKWebViewer-Plugin for macOS… but I’d love to get this working with “pure Xojo” (Declares are fine).

[quote=484373:@Jürg Otter]It seems to me that HTMLViewer on macOS does not even try to load such an Redirect: oob://testapp/callback#id_token=abcd1234.
The other Operating Systems will either try (so you can intercept .CancelLoad) or show an error page (and you get to see the desired value in .DocumentComplete).[/quote]
This is what I get:

Windows 10, Renderer: WebKit

CancelLoad: oob://testapp/callback#id_token=abcd1234 DocumentComplete: chrome-error://chromewebdata/ TitleChanged: oob://testapp/callback#id_token=abcd1234

Windows 10, Renderer: Native

TitleChanged: Xojo HTMLViewer - Callback Test TitleChanged: Die Webseite kann nicht angezeigt werden DocumentComplete: oob://testapp/callback#id_token=abcd1234

Ubuntu 18.04

CancelLoad: oob://testapp/callback#id_token=abcd1234 DocumentComplete: oob://testapp/callback#id_token=abcd1234

So in all Operating Systems above I get the desired id_token.

macOS 10.15

TitleChanged: Xojo HTMLViewer - Callback Test DocumentComplete: CancelLoad: DocumentBegin: CancelLoad: DocumentComplete:
No id_token anywhere - I don’t get to see that custom URL/Scheme at all :frowning:

I’ve said this before, we need CEF (or at least the option to have it included) across all platforms to guarantee a proper xplat behavior. On Mac it uses another engine and it does things like this.

I’ve found a couple of ways to get the desired result on macOS…

  • use a Xojo Version that contains this: <> (not an option for our production builds)
  • MBS Plugins, which provide WKWebView for XojoVersions that still use HTMLViewer with WebView (downside: a lot of MBS Plugins required for all dependencies… just to intercept a Redirect with a custom URL Scheme)
  • use Xojo’s default HTMLViewer (WebView based), and MBS Plugins to leverage WebPolicyDelegateMBS (downside: same as before - a lot of Plugin parts are needed for such a basic functionality)
  • do it yourself with Declares and no Plugins required (and no full-blown macOSLib or similar needing to be added to the project)

Since the last option is the most interesting one, here’s the updated example project.

What it does:

  • creates an own WebPolicyDelegate
  • use the own/customized one instead of how it’s implemented by the Xojo Framework (but forward to it, to still get Xojo’s standard behavior)
  • the custom WebPolicyDelegate will invoke a Delegate, so that you can see the Navigation Actions going on (which Xojo’s implementation wouldn’t show all, e.g. that custom URL Scheme)

As a result, you’ll see that Redirect to the custom URL Scheme oob://testapp/callback#id_token=abcd1234 in the Delegate Handler: WebViewNavigationActionURLRequestDelegateHandler

macOS 10.15 (HTMLViewer, modWebKitWebPolicy)

CancelLoad: DocumentBegin: WebViewNavigationActionURLRequestDelegateHandler: oob://testapp/callback#id_token=abcd1234 DocumentComplete:

Maybe this helps someone else running into a similar situation…