We talked about the differences between using proxied and inline content within a gadget in Chapter 3 in the section Inline Versus Proxy Content. Depending on the architecture and needs of their application development environment, many developers may prefer the proxied content approach for its ease of use.

If the markup for the Content sections of your gadget is defined with a proxied data source, the way you make container data sources available to that file is very similar to the methods we have used in earlier sections:

<Content type="url" view="canvas" href="http://www.mysite.com/canvas.php">
  <os:PeopleRequest key="ownerFriends" userId="@owner"
                    groupId="@friends" startIndex="10" count="20"
                    fields="name,nickname,gender,birthday" />
</Content>

We define our Content node, with our proxied content being loaded through the file specified in the href attribute. Normally, when using proxied content, we would have a self-closing Content node, but to add the container data we instead embed the data source that we are looking for—in this case, a subset of the application owner’s friends.

Once the proxied content source is fetched, all of the data sources requested will be passed to the file as POSTed JSON objects. If the container cannot also send the opensocial_owner parameter (which contains the unique identifier for the owner) to the third-party server, then references to @owner will return a 403 forbidden HTTP error. The same would hold true if we were using the @viewer or @me values and the container could not send the opensocial_viewer parameter.