Chapter 4 SocialSite Host Requirements

The Sun Glassfish SocialSite software is an end-to-end solution that adds social features to existing web applications by providing a server to manage the social graph, as well as a library of social widgets that can be added to an existing web page. There Enterprise Social Server implements the OpenSocial REST APIand the OpenSocial JavaScript API so that existing web applications do not have to be rewritten from scratch to create a social application.

As implemented, the SocialSite software has the following prerequisites in order for a host application to be socially enabled:

• the host application is capable of rendering dynamic web pages

• the host application must have the authority to verify user identities

Once the prerequisites have been satisfied, a host application can be socially enabled by meeting the following requirements:

• create a page for the context delegation service

• add SocialSite widgets.

• create a page to return user context.

Dynamic Web Pages

The SocialSite software is intended to work with dynamic web pages. Dynamic pages can change content on a web page in response to different contexts or conditions (such as by user role):

• The SocialSite server uses a server-side scripting language (such JSP or PHP) to change the sequence of web pages or web content presented to the browser. The SocialSite server follows the OpenSocial REST API specification to manage:

  • user and friend profile data

  • activities

  • persistent data

The SocialSite widgets follow the OpenSocial JavaScript API specification to manage the presentation within a web page by changing the interface behaviors in response to mouse or keyboard actions or at specified timing events.

Authentication Delegation

The OpenSocial specification requires that every user ID must be alphanumeric (A-Za-z0-9) and must uniquely identify the user in a container. This standardization is intended to allow for prefixing IDs with a domain name and separator to create globally unique IDs.

The SocialSite server satisfies this requirement by delegating the authority to verify user context to the host application. This means that the SocialSite server does not perform user authentication when there is a request to access the social graph from a widget installed on a user's web page. A host application is responsible for the following:

• It must have some form of user authentication (such as the getRemoteUser method in the code example) so that a request from the SocialSite server to verify a user identity will cause the host application to return a valid user ID. Typically, user authentication consists of a log in page where user names and passwords are verified and stored.

• It must include a file (such as socialsite_context.jsp in the code example) that implements an authentication delegation service for the SocialSite server. The SocialSite server sends a request for this file to your host application using the same cookies as the client would. This is how the host application can assert the identity of the current user to the SocialSite server.

Refer to the article on the SocialSite security model for more information.

Creating the Authentication Delegation Service

This is an example of what a web application may include as a context delegation service page (socialsite_context.jsp). Although a JSP file is used here, the concepts should directly translate to other page-generation languages (such as PHP):

01: <context>
02:  <viewer>
03:   <user name="<%=request.getRemoteUser()%>" />
04:  </viewer>
05:  <owner>
06:   <user name="<%=request.getRemoteUser()%>" />
07:  </owner>
08: </context>

The sample code returns an XML representation of the identity context for the current user's session. Note that the "context delegation service" is not required to be included within the host application, In this example, it is convenient to include the context delegation service within the host application to leverage a local HttpSession context.

Adding the SocialSite Widgets to the Host Application

Here is an sample of what a host application may include in its source code to add a SocialSite widget (profile.jsp):

01: <html>
02:  <head> 
03:   <script type="text/javascript" src="http://socialsite.example.com/js/consumer.jsp"></script>
04:   <script type="text/javascript">
05:    socialsite.setContext({
06:      'attributes': {
07:        'ownerId': '${ownerProfile.userId}'
08:      },
09:      'delegate': {
10:        'method': 'GET',
11:        'url': '&lt;%=request.getContextPath()%>/socialsite_context.jsp',
12:        'headers': {
13:          'cookie': document.cookie
14:        }
15:      }
16:    });
17:   <script>
18:  <head>
19:  <body>
20:   <script type="text/javascript">socialsite.addGadget({'spec':'http://example.com/gadget.xml'});</script>
21:   <script type="text/javascript">socialsite.addGadgets({'collection':'PROFILE'});</script>
22:  </body>
23: </html

Creating a Page to Return User Context

The socialsite_context.xml file needs to be to the classpath of the SocialSite Enterprise software to specify the location of the context delegation service in order to assert a user ID. Here is a sample file:

<rules>
?
	<rule>
?
	<sources>
<indirect>*</indirect>
</sources>
?
	<attributes>
<accept>*</accept>
<reject>viewerId</reject>
</attributes>
</rule>
?
	<rule>
?
	<sources>
?
	<direct>
http://socialsite.example.com/socialsite_context.jsp
</direct>
</sources>
?
	<attributes>
<accept>*</accept>
</attributes>
</rule>
</rules>

Note that this file contains the URL of the context delegator service that you created. You can add this file to your classpath by copying it to your glassfish/domains/domain1/lib/classes/ directory, which should already contain a socialsite.properties file that was added during installation. Restart the GlassFish server to include the changes.