Problems with NavigateToLocalStreamUri and Intranet Links

WebView's NavigateToLocalStreamUri is a method used by developers who want to locally host content in their Windows Store app and display it fully, including images and other locally hosted content, a function which NavigateToString fails to do.  You can read about how to implement this in my previous blog post.

TL;DR: NavigateToLocalStreamUri can’t access intranet sites due to IE Zone Elevation.

One of my coworkers in Japan noticed that intranet links inside the pages rendered by NavigateToLocalStreamUri do not work.   It's interesting, however, as links that go to external sites work just fine.  And just to be clear about this, the app was given the Private Networks (Client & Server) capability. For visualization, this is an example of what I worked with:

The four links inside this WebView are generated by a page rendered using NavigateToLocalStream.  The first two links are to an external source (Bing.com) and the second two links point to an intranet resource.  The first two links operate normally:

External link clicked. This opens Bing in the WebView.	External link using target="_blank" clicked. This opens a new IE instance.

 
I investigated this scenario and did not find anything obvious, so I spoke with our Mike Jackson, Sr. SDE Lead for WebView about the issue. There are two ways to work around this problem (not equally well):

1) You can inject JavaScript into WebView in order to force the WebView to navigate.  It’s necessary to do this because the click does not fire any kind of Navigation events. It’s not the most elegant solution, but the only one that works in this case without any additional prompting. Relevant code: 

HTML:

 <a href="#" onclick="window.external.notify(‘https://IntranetSite')">https://IntranetSite by notify</a>

XAML page:

 <WebView Grid.Row="1" x:Name="wvTest" ScriptNotify="wvTest_ScriptNotify"/>

Code-behind:

 private void wvTest_ScriptNotify(object sender, NotifyEventArgs e)
{
  wvTest.Navigate(new Uri(e.Value));
}

2) The reason that this problem occurs is that the page loaded by NavigateToLocalStreamUri is loaded into the IE Internet Zone.  When trying to navigate to an link without a dot (.) in the name, the endpoint is considered to be in the IE Intranet Zone.  WebView tries to prevent maliciousness by preventing zone elevation.  In order to get around this, you can remove the Private Networks (Client & Server) capability.  The reason this works is that the app now does not consider that it automatically has permission to access an Intranet site, and it prompts you for permission to access the page:

Once permission is given, the appropriate credentials are in place to ensure that zone elevation can take place.

I hope this post helps you get past this issue. 

Comments are encouraged, and feel free to tweet to me at @WinDevMatt. My team’s hashtag is #WSDevSol.