I’m working on a client project to replace their existing macOS-only app (written in Swift) with a nice JUCE-y version that is Windows/Mac.
Here’s the difficulty that I’m running into: they are using a 3rd party authentication provider that handles all of the OAuth stuff through a RESTful API. We start the process by constructing a URL with query parameters and loading that into a WebBrowserComponent.
On Windows, my JUCE code runs through the authentication flow without incident. On Mac, the auth flow bombs out while things are at the auth provider (happening inside the browser component).
The client has helpfully created a minimal working version of their app in Swift, which starts the in-browser process and runs it to conclusion. Since the only variable here that’s under our control is that initial URL to load, I copied the URL that they create into my application as a string literal, and the system fails in the same way, so I’m confident that the problem isn’t in my code that constructs that URL.
The only visible difference that I can see at this point between the JUCE/C++ and Swift apps is that JUCE uses the older WebView component (now deprecated for apps targeting 10.10 or later) and theirs is using the current WKWebView component.
While we wait for the auth vendor to explain their error code:
Am I off-base for thinking there’s any chance that the embedded browser component could have an impact here? (No, I don’t have a great hypothesis for how that might be the case. User-agent strings? Some other low-level header(s) that get added?)
Are there plans to update the macOS WebBrowserComponent as 10.10 recedes further into the distance?