I'm writing a Windows 8.1 app which accesses a REST API w/ OAUTH. I displayed the login using an x-ms-webview control. This has worked fine since I implemented it.
Now, I need to switch from their production server to their development one to start adding some new features. The authorization works the same, but the production server was publically available, while the dev server is only accessible on the company intranet.
Attempting to access the dev server results in Windows blocking the request unless I add "Private Networks (Client & Server)" to the apps capabilities in package.appxmanifest. That's fine, but when the feature is enabled the authorization fails to redirect correctly and I'm instead presented with a blank screen.
Strange thing is, the production server has the same issue when "Private Networks" is enabled (even though it's a publically accessible server). Yet loading the same markup on a page served to localhost will redirect correctly. The WebView must react differently if it's hosted locally or externally (be it intranet or internet). Does anyone know how the WebView behavior changes with respect to the "Private Networks" flag and how I might be able to access an intranet site?
I suspect that Windows is blocking the redirect due to the possibility of a proxy. With intranet access you could set up a proxy that accessed the greater internet fairly easily, even if it weren't enabled in the app's features. However I do have the "Internet (Client)" feature enabled, so that isn't a security concern.
Does anyone have any idea how to get around this issue?
After much pain and suffering I discovered that the reason the WebView wasn't following the redirect is because the redirect was to localhost (authorization code was in the URL's query parameters). Apparently, Windows refuses to visit localhost when "Private Networks (Client & Server)" enabled. I don't completely understand why apps can't access localhost, but apparently Windows instantly refuses those connections.1
@Microsoft: Visual Studio threw a warning when I tried to connect the intranet, telling me that Windows actively refused the connection because I hadn't enabled "Private Networks (Client & Server)", an issue I was able to fix in seconds. You could have saved me two weeks if you had done the exact same thing with this and just said "Windows refused a connection to localhost because 'Private Networks (Client & Server)' is enabled." Is there a reason that didn't happen? /rant
I was able to fix this by having the server redirect to a 404 page on its own domain rather than going to localhost. Windows accepted that connection and I was able to get the authorization code from the URL and do my thing.