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
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: https://www.jo-tools.ch/xojo-callback-test/
CancelLoad: https://www.jo-tools.ch/xojo-callback-test/
DocumentBegin: https://www.jo-tools.ch/xojo-callback-test/
CancelLoad: https://www.jo-tools.ch/xojo-callback-test/
DocumentComplete: https://www.jo-tools.ch/xojo-callback-test/
No id_token
anywhere - I don’t get to see that custom URL/Scheme at all
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: <https://xojo.com/issue/52330> (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: https://www.jo-tools.ch/xojo-callback-test/
DocumentBegin: https://www.jo-tools.ch/xojo-callback-test/
WebViewNavigationActionURLRequestDelegateHandler: oob://testapp/callback#id_token=abcd1234
DocumentComplete: https://www.jo-tools.ch/xojo-callback-test/
Maybe this helps someone else running into a similar situation…