ShowTable of Contents
< 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
- 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.
Setting the container URL to http://<OpenSocial Component Location>/fiesta/notesdomino/notesdominocommoncontainer.html
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 >