Mar 09

It took me some time, but I finally managed to get the concepts of local vs. web contexts. It took some time not because they’re that difficult, but because the Windows 8 Metro docs are still a mess (which is understandable, since we’re still at beta – pardon me, I mean Consumer Preview) and finding someone with the time to explain it to me was not really as easy as I thought it would be. Anyways, that’s past, so lets get started.

WinJS app’s code can only be run in one of two contexts: local or Web. The need for having two contexts is motivated by the need to run code coming from different origins. For instance, you might need to embed a map in your app to enhance the way you present data to your users. In fact, you’ll probably need to interact with that map through code. Now, currently this might mean embedding a script reference to Google or Bing maps, and that really means we’ll have code written by others being executed in our app. Another good example of running external code is advertising. Typically, this also means adding a reference to an external script

If all the resources would run with the same privileges, then we might get into trouble because we can’t really know what all the 3rd party libraries do and we can’t really guarantee that all of them don’t have any malicious code (I’m sorry, but that’s just life!). And that’s why we have the concept of local vs. web context. The execution context under which a resource runs is responsible for granting features and imposing restrictions. For instance, all pages running in the local context can have full access to the WinRT and to the WinJS (some of those features depend on configuring the manifest to ask them to the final user) or even make cross domain calls (through XHR), but can’t reference any external scripts nor execute code by using the “javascript:code” scheme in an URI. Now, when code runs in the web context, some of these restrictions go away (ex.: external script references are allowed), but you’ll have new ones. For instance, you won’t be able to access the WinRT and you’ll only be able to access part of the WinJS features (for a list of these limitations, please read this).

Now, the important question: when does a resource gets executed in the local context and when does it get executed in the web context? Generally, people say that local content (i.e., content maintained inside the app’s package) runs in the local context and all external resources run in the web context. Even though this is correct in most cases, this definition is not really accurate. In fact, the platform will resort to the http scheme of a resource’s URI to see if it should be executed in the local or in the web context. All the resources using the ms-appx, run the in the local context and everything using the http, https or ms-appx-web scheme will be run in the web context. Now, ms-appx is used by default to reference resources maintained inside the app’s package (and you won’t be seeing them often unless you’re getting stuff from an external package). We all know what http and https are used for, so there’s not much to say here. What about ms-appx-web? Well, that’s the interesting one…You can use it to make a local resource run in the web context. When will you want to do this? Well, it might be a good option when you’re building mashups. For instance, suppose you want to add a map and need to write some JS code to interact with it. Since maps are added through external references, then you can’t insert them in your top page because that page will always run in local context. In that case, you can always build another local page which references the external map and has JS code to interact with it. Then, you can add an iframe to your top page which references that auxiliary local page through the ms-appx-web scheme (instead of using the default ms-appx scheme).

Btw, if you’re writing code and you need to know if you’re currently running in the local or in the web context, the easiest way to perform that check is to see if the Windows object exists or not (Windows, not window, ok?)

Now that we know the difference between both contexts and how resources are executed in one or the other, we still need to take a look at the ApplicationContentUriRules section (if you’re using the UI manifest editor, then I’m talking about the Content URIs tab). If you look at the docs, you’ll notice that this element “specifies the boundary of an app in terms of internet domain and URLs that the system hosting the app considers part of the app”. In other words, you can use this section to grant some extra privileges to external content which is going to be loaded in the web context. If I’m not mistaken, you’ll need to add an include rule to this section for any external content that tries to access the clipboard or get geo info from the geolocation object. Notice that you still won’t be getting any access to the WinRT. You can also add exclude rules and these should be useful when you want to allow a domain to access these features, while at the same time preventing a specific URI from being able to access them (this is possible because the URI specified can use a pattern for matching).

And I think this should make things clearer, right? Bottom line: a resource can only run in the local or in the web context and you can use the ApplicationContentUriRules section to allow external resources to access to the clipboard and geolocation objects.

And that it’s for now. Stay tuned for more.

1 comment so far

  1. Sharla Minkowitz
    4:17 pm - 6-28-2012

    There is perceptibly a bunch to realize about this. I believe you made certain nice points in features also.