< Previous | Cookbook Contents | Next >

Overview

The OpenSocial Component renders OpenSocial gadgets in three distinct ways depending on which client is being used as well as what type of OpenSocial gadget is being rendered. This article outlines those three distinct processes at a high level so that administrators can understand the process and also understand where to find logs if one of the rendering processes fails.

iNotes Rendering

When OpenSocial gadgets are rendering in iNotes, the browser will render the gadgets in an iframe on a domain alias for the Domino Server with Shindig. This is the locked domain that is configured in the Server-centric settings article. The gadget iframe will load resources through the OpenSocial Component's proxy on the Domino Server with Shindig using the unlocked domain that is configured in the Server-centric settings article. The gadget will also make XML Http Requests (XHR) to the Domino Server with Shindig on the locked domain.

iNotes client-side code will call REST APIs on the Mail Server:

• To manage Widgets
• Getting all of the Widgets currently installed for the current user, including information dictating whether the Widget is approved to render by a trusted administrator
• Adding a widget from the Widget Catalog
• Updating widgets that are already installed using the "Update Widgets" menu of the "My Widgets" sidebar

iNotes client-side code will call REST APIs on the Domino Server with Shindig:

• To establish OpenSocial container security tokens
• To load OpenSocial container JavaScript that is necessary to render OpenSocial gadgets and Embedded Experiences
• To get metadata about OpenSocial gadgets and Embedded Experiences being rendered
• To refresh aforementioned security tokens
• Note: All of the calls outlined here take place through the iNotes Mail Server's proxy; hence, the "Proxies" configuration in the Security settings document as outlined in the User-centric settings article

The OpenSocial Component OSGi bundles on the Mail Server will read:

• Read data from the Widget Catalog replica on the iNotes Mail Server
• Hence, there is a requirement to have a Widget Catalog replica on each iNotes Mail Server as outlined in the Database creation and configuration article
• Read/write data to the current user's mail file

The OpenSocial Component OSGi bundles on the Domino Server with Shindig will read data from the Credential Store

• Gadget and Content proxy whitelist rules to filter proxied requests that an OpenSocial gadget makes at runtime
• Gadget capabilities that an OpenSocial gadget has access to at runtime
• OAuth1.0a consumer and access information that will be used when an OpenSocial gadget uses authenticated request mechanisms
• OAuth2.0 consumer, access, and refresh information that will be used when an OpenSocial gadget uses authenticated request mechanisms

Notes Rendering

OpenSocial gadgets and Embedded Experiences that render in the Notes client may render in one of two ways: render locally or render remotely. Rendering locally means the OpenSocial Component installed on the Notes client will handle all aspects of the rendering. Rendering remotely means the OpenSocial Component on the Domino Server with Shindig handles the rendering while the OpenSocial Component installed in the Notes client handles other aspects of the rendering process, such as trust management.

Rendering remotely occurs in two cases: when a gadget uses OAuth and when a remote override is set.

One can determine if a gadget is using OAuth in one of two ways. The first method is to check the OpenSocial gadget definition for the presence of <OAuth> or <OAuth2> sections. The second method is to check the Widget extension.xml for <grant-feature id="oauth-definition"/>. Gadgets using OAuth cannot render locally because OAuth data stored in the credential store cannot be securely replicated to the Notes client for use.

A gadget may also render remotely when a remote override is set, forcing all rendering in the Notes client to happen remotely. This is useful in environment like Citrix where it is desirable to reduce the client footprint as much as possible. See IBM Notes Social Edition clients using Citrix and OpenSocial gadgets need to be configured to render gadgets remotely for more information.

The Notes client logs will report information on where the OpenSocial gadget or Embedded Experience is rendering. The OpenSocial Component location will be "localhost" when rendering locally or the hostname of the Domino Server with Shindig when rendering remotely.

Local Rendering

When rendering locally in Notes, the OpenSocial Component will read data from the local replica of the Widget Catalog. It will query the My Widgets framework to verify that the gadget is approved to render in the client by a trusted Widget Catalog administrator. It will also read proxy whitelist data and gadget capabilities that control what data the gadget can access through the proxy and what gadget APIs are available to the gadget at runtime, respectively. Remember, no OAuth data can be read from the Widget Catalog because it does not exist. If the gadget was using OAuth, it would be rendering remotely.

Remote Rendering

When rendering remotely in Notes, the OpenSocial Component in the Notes client will query the Widgets framework to verify that the gadget is approved to render in the client by a trusted Widget Catalog administrator before initiating the remote rendering process. The gadget rendering process is delegated to the remote OpenSocial Component on the Domino Server with Shindig. From this point, the rendering process is very much like the iNotes rendering process, where the proxy data, gadget capabilities, and OAuth information are read from the Credential Store.

< Previous | Cookbook Contents | Next >