ShowTable of Contents
< Previous | Cookbook Contents | Next >
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.
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.
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
client-side code will call REST APIs on the Domino Server with Shindig
- To establish OpenSocial container security tokens
- 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
- 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
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
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.
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 >