Tag Archive for 'xbap'

As Tim Sneath announced earlier in his blog today, the British Library has released a just awesome XBAP. 

I’ve been giddy about this app since I saw the first prototype.  Here’s an example of technology really opening doors and offering new experiences.  The public can see these Da Vinci’s notebooks, Mozart’s compositions, and many other (usually locked up) rare books in a fuller fidelity, richer environment than ever before.

Tim goes in to all the specific coolness of the app in his post.  I definitely recommend the read.

Try out ”Turning the Pages” here.

XAML Browser Applications (XBAPs) in this version are promptless in-browser experiences. 

This has many implications:

1. clean experience when navigating to an XBAP.  (There is no Information Bar or security warning before launching the app.) 
2. cached (not installed) on the user’s machine.
3. security sandbox.

Sandboxed Applications

The third bullet above is especially important for XBAP developers.   XBAPs obey the security contract of being in the browser: they are sandboxed according to their deployment zone.  Today, there is no way to seamlessly “elevate” and prompt the user for additional permissions.  (This is an often-requested feature and something we are investigating for future versions.)  The sandboxed restriction also means that XBAP developers need to be conscious of the bounds of the security sandbox as they develop their app.  (See previous post.)

Note: By default, all XBAPs request the Internet Zone permission set in their application manifest.  In V1, there is no significant difference between the Internet & Intranet permission sets.

“I want my XBAP to run with full trust.  I heard there are workarounds..?”

Given the sandbox restrictions and the wide range of experiences desired in the browser, this is not surprisingly a frequently asked question about XBAPs. 

If you want full trust, you should first consider building a standalone installed WPF application.  These by default run in full trust and can be deployed using ClickOnce, giving many of the deployment benefits of a browser application.

If your scenario requires that you’re an XBAP, there is no built-in way for XBAPs to prompt and request more permissions. That being said, XBAPs are ClickOnce applications behind the scenes.  That means it is possible to use ClickOnce-based methods to gain access to trusted actions.  There are two main options:

1. Install an AllowPartiallyTrustedCallersAttribute’d (APTCA)assembly in to the client’s Global Assembly Cache (GAC).  Use this full trust assembly to proxy calls for the XBAP.
2. Install a certificate in to the user’s trusted publisher’s store.  Use ClickOnce trusted application deployment by signing the XBAP with the certificate.

Neither of these workarounds are ideal from a security standpoint, but we believe the latter is the better option.

GAC’d APTCA assemblies are accessible to ALL partial trust callers and therefore are susceptible to repurposing by 3^rd parties.  There are ways to mitigate this exposure – for instance, one could use the [InternalsVisibleTo] attribute to only expose methods to specific “friend” XBAP assemblies.  However, mistakes or incomplete usage of this mitigation could potentially open wide security holes.  In addition, the management of installed APTCA assemblies is very end-user unfriendly.

For intranet XBAPs, pushing out a trusted publisher certificate through group policy is a fine way of enabling LOB scenarios. 

However, for consumer scenarios, trusted deployment via trusted publisher certs has its drawbacks.  This is because it affects more than just XBAP deployment:  many trust decisions prompts are bypassed for trusted publishers.  Still, this workaround has the advantage of being scoped to the specific publisher.

For V1 consumer XBAPs, we make the following recommendations:

1. Be sure your app needs to be an XBAP.  (Can it be a full trust standalone ClickOnce application?)
2. Trusted app deployment is preferred of the two workarounds.
3. Use a separate cert to sign each XBAP group.  Otherwise, a user who decides to trust one set of XBAP will implicitly agree to trust all XBAPs (& ActiveX controls, etc) signed with that certificate.  This scopes the security impact (and responsibility) of any particular certificate.
4. Use an MSI to install the cert.  This ensures installation is consistent with the configured security installation settings on the client machine (e.g. requiring Admin rights).
5. Install the cert into the user’s trusted publisher store, not the machine’s.  This reduces the machine decisions that the trusted publisher cert can impact.
6. Clearly notify the user at installation that they are changing the user’s trusted publisher store. 
7. Provide clear installation instructions on the page containing the XBAP.  If the cert is not installed and the XBAP requests full trust, a “Trust Not Granted” error is shown.

Please use the above method with extreme care. We’re exploring changing XBAP elevation to work better in future versions.  Your feedback in this area, as always, is appreciated.

Other FAQs

How did you implement the sandbox?

The XBAP sandbox is based on the .NET Framework security model: Code Access Security.  In this model, permissions gate the actions that a particular app can do (i.e.  FileIOPermission controls file system access).  What permissions are granted depends on what deployment zone an application is deployed from.  A detailed explanation on our implementation strategy can be found in the WPF Sandbox Whitepaper.

When will you be expanding the sandbox?

We’ve had a lot of requests for specific features to be brought in to the Internet sandbox.  Currently, we’re exploring plans for our next version.  We would love feedback if there is a non-sandboxed feature that is blocking you.  Please leave comments on this blog post or send requests to wpfsec at microsoft dot com.

Source code for the Contoso Healthcare Application is now posted on the community site! (Thanks Karsten!)

This is a great app. (I demoed it at TechEd Southeast Asia & its been shown at many other events as well).  It showcases, among other things:

1. 3D fliptransitions.  (This UX paradigm is similar to a doctor’s real world experience of flipping through a patient chart.)
2. Data visualization on a 3D surface for fast comparison.
3. Listbox styling dependent on level of information desired.
4. Annotations on video.
5. Patient diagnosis in flow document format.

Get the code here.

As Mark Alaczar points out in his WPF sandbox whitepaper, sandboxed top level navigation requires user initiation.

Some definitions to help this make sense:

• Top level navigation: Navigations that target the hosting web browser. For instance, navigating the entire browser, or a specific HTML <iframe>, to http://netfx3.com.
• User initiated: Direct result of an explicit user action. In the case of top level navigation, this is most likely the user clicking on a hyperlink. “Programmatic”, on the other hand, is the direct result of a dev action, like NavigationService.Navigate(…).

In this version of WPF, top level navigations in sandboxed apps require “user initiation.” Today, only the Hyperlink class has this notion of “user-initiatedness,” and it cannot (for security reasons) be subclassed in the internet sandbox.

There are many cases, however, where a more interesting Hyperlink than the default is desired. This post uses styling to create an image hyperlink that works in the internet sandbox.

Hyperlink is an inline-level flow content element that derives from TextElement, not ContentControl. This means it must be put inside of a text element container like Paragraph or TextBlock.

To create a more general control that can be used in different layout containers, you can use a ContentControl with the following style:

<ControlTemplate TargetType="ContentControl" x:Key="Hyperlink">
  <TextBlock Text="" TextWrapping="Wrap">
    <Hyperlink TextDecorations="" NavigateUri="http://www.netfx3.com">
      <Image Style="{StaticResource HyperlinkImage}">
      </Image>
    </Hyperlink>
  </TextBlock>
</ControlTemplate>

You can than style the image, perhaps adding a mouse over trigger:

<Style x:Key="HyperlinkImage" TargetType="{x:Type Image}">
  <Setter Property="Source">
    <Setter.Value>
      <BitmapImage UriSource="flowers_color.jpg"/>
    </Setter.Value>
  </Setter>

  <Setter Property="HorizontalAlignment" Value="center"/>
  <Setter Property="VerticalAlignment" Value="center"/>
  <Setter Property="Stretch" Value="Uniform"/>
  <Setter Property="IsEnabled" Value="true"/>

  <!-- Hover Trigger to change image source-->
  <Style.Triggers>
    <Trigger Property="Image.IsMouseOver" Value="true">
      <Setter Property="Image.Source">
        <Setter.Value>
          <BitmapImage UriSource="flowers_bw.jpg"/>
        </Setter.Value>
      </Setter>
    </Trigger>
  </Style.Triggers>
</Style>

Then create the ContentControl itself:

<WrapPanel Margin="40" Orientation="Vertical">
  <ContentControl  Width="100" Template="{StaticResource Hyperlink}"/>
</WrapPanel>

You can try it out in loose xaml here.

When relying on resources living on a server, you can increase client app perf & decrease network traffic by storing local versions. When trying to build a sandboxed XBAP, however, you cannot create your own local cache store in the file system beyond the space available in isolated storage (512KB).

Fortunately, WPF resource loading uses System.NET’s HttpWebRequest and its “Default” caching policy. In addition, depending on your resources’ sizes and your scenario, it may make sense to use a non-default caching policy when issuing your own HttpWebRequest.

This post aims to give you a little bit of caching context, an overview of your caching options and some sample code.

Understanding the HTTP Cache

How long is something good for?
This answer is determined through a combination of server & client settings.

The server sets the HTTP Response Header “Expires” to indicate the time after which a resource is considered stale. A stale cache entry may not normally be retrieved unless it is first validated with the origin server as being the current version. In addition, the server may specifiy certain cache directives in the header. These include “no-cache,” “max-age,” and “must-revalidate.”

The client/app’s cache policy can determine whether or not a “stale” or even a “not yet stale” value should be returned. Some of these policies are time based (e.g. “okay if stale only for X days”) or location based (“return cached value if it’s there and meets server specified revalidation requirements.) However whatever the app’s cache policy, it must respect the server’s cache directives.

System.Net’s Cache
System.Net.HttpWebRequest’s cache uses the IE cache. This has many benefits: there is a single place for user management perspective. Also, a shared store widens the chance that a recent response might have already been cached. The IE cache (“inet cache”) uses the Temporary Internet Files (“TIF”) to cache results of HTTP requests. Some details:

System.Net.HttpWebRequest’s cache uses the IE cache. This has many benefits: there is a single place for user management perspective. Also, a shared store widens the chance that a recent response might have already been cached. The IE cache (“inet cache”) uses the Temporary Internet Files (“TIF”) to cache results of HTTP requests. Some details:

• (Update 11 Oct 06)The TIF is by default 3% of the harddrive on XP and 50MB on Vista. This amount is user configurable.
• The TIF is clearable by users through the Internet Options control panel. It is scavenged when full.
• On Vista, IE7 Protected Mode puts Low Integrity Level content in a separate cache.

Understanding the most common cache matrixes
The below table calls out some of the most common caching policies. (Note: We assume that no additional server cache constraints were set other than Expires header.)

Note: If the server does not set the Expires http header, than the expiration=none. In this case, the machine determines what the right “Freshness” time for the resource. By default, this is 1 day but it is configurable.

Note: For System.Net.HttpWebRequest, “Default” policy is somewhat misleading. Unless you explicitly set HttpWebRequest.CachePolicy (or HttpWebRequest.DefaultCachePolicy), the policy is “BypassCache.”

What cache version to use
If your resource files are large & unlikely to change (and having current version is not critical), you should consider:

• Set a large value in your resources HTTP Expires header
• Set cache policy to HttpRequestCacheLevel.Default.

If it is critical to have the current version of the resource, you should consider:

• Set cache policy to HttpRequestCacheLevel.Revalidate.

If you don’t want a unique caching policy, you should stiil:

• Manually set the cache policy to HttpRequestCacheLevel.Default when creating your own HttpWebRequests

How to set cache policy
Here is a code snippet:

      //  eCreate request
      HttpWebRequest request =
         (HttpWebRequest)WebRequest.Create(requestURI);

      //  Create & set cache policy
      HttpRequestCachePolicy cachePolicy =
         new HttpRequestCachePolicy(HttpRequestCacheLevel.Default);
      request.CachePolicy = cachePolicy;
 
      //  Send request/Get response
      HttpWebResponse response = (HttpWebResponse) request.GetResponse();

      //  Put response in to stream
      Encoding enc = Encoding.GetEncoding(1252);
      StreamReader responseStream =
         new StreamReader(response.GetResponseStream(), enc);

      //  Manipulate Response stream
      //  Cleanup
      response.Close();
      responseStream.Close();

 Resources to more deeply understand standard caching

•  System.NET Cache Management for Networks Applications Overview
• HTTP Protocol RFC 2616 (See sections 13 & 14)
• I’ve also written a small xbap to demonstrate grabbing a text file from the web using the different caching mechanisms. You can run it here or look at the code.