Revision as of 15:33, 5 November 2016

Client Context library for gCube Portlets

Starting from gCube 4.2, a new mechanism to retrieve the current user identifier and the current context identifier at client side has been introduced for gCube's portlets. The Client Context library allows to easily retrieve these information by relying on the Liferay.ThemeDisplay javascript object ^[1], and inject them at server side (they are transparently sent along the header of the remote requests). There you should use the PortalManager library^[2], to retrieve and convert them automatically to the current user and gCube context.

The Client Context Widget

The Client Context has been developed as a GWT Widget. Its source code is available in the gCube SVN repository, at this url. Basically, it offers two self-explanatory methods

public static native String getCurrentContextId();

and

public static native String getCurrentUserId();

This code is translated to native Javascript code, starting from pure Java code by the GWT Framework. Please note that both methods actually return a number value.

To use the widget, you need to declare the following maven dependency in your project's pom.xml

<dependency>
        <groupId>org.gcube.portal</groupId>
	<artifactId>client-context-library</artifactId>
	<version>[1.0.0-SNAPSHOT,)</version>
	<scope>compile</scope>
</dependency>

as well as the following line in the gwt.xml file of your gwt-portlet:

<!--Inherit the GCubeClientContext widget code -->
<inherits name='org.gcube.portal.clientcontext.GCubeClientContext' />

Finally, in the onModuleLoad() method of your gwt web application, you must declare the following code line

public class ... implements EntryPoint {
 
  public void onModuleLoad() {
 
     /**
      * Inject client context to automatically pass the context id and the user id to the server side 
      */
      GCubeClientContext.injectContext();
 
      ...
   }	  
 }

Portlet Example

A portlet example's source code is available url. It uses both the Client Context library and the PortalManager library, together with the UserManagement library ^[3], which abstracts Liferay's concepts and map them to gCube's ones. Once deployed on Liferay, the portlets looks like

As you can see, the Javascript client code automatically set the user identifier and the context identifier by using the ClientContext methods reported above. By pushing on the button Retrieve, a remote request that has in the header the group id and the user id is sent to the server side, and the Portal Manager is used to retrieve the current user (given the user identifier) and the context (given the group id), as follows:

/**
 * Server side implementation.
 * @author Massimiliano Assante at ISTI-CNR (massimiliano.assante@isti.cnr.it)
 * @author Costantino Perciante at ISTI-CNR (costantino.perciante@isti.cnr.it)
 */
public class ClientContextExampleServlet extends RemoteServiceServlet implements GcubeContextExampleServices {
 
    private static final long serialVersionUID = -8208421700660483142 L;
 
    // Logger
    private static final org.slf4j.Logger logger = LoggerFactory.getLogger(ClientContextExampleServlet.class);
 
    @Override
    public String getInjectedUserid() {
 
        // Read user id from the request, using the PortalContext
        try {
            HttpServletRequest request = this.getThreadLocalRequest();
            return PortalContext.getConfiguration().getCurrentUser(request).getUsername();
        } catch (Exception e) {
            logger.debug("Failed to retrieve the user id", e);
        }
        return null;
    }
 
    @Override
    public String getInjectedContextid() {
 
        // Read context id from the request, using the PortalContext
        try {
            HttpServletRequest request = this.getThreadLocalRequest();
            return PortalContext.getConfiguration().getCurrentScope(request);
        } catch (Exception e) {
            logger.debug("Failed to retrieve the context id", e);
        }
        return null;
    }
 
}

The result after the methods invocation is this one

Tips for Development Environment

The client context relies on Liferay.ThemeDisplay javascript object, which obviously is not available if you run your application outside the real D4Science's portals. Moreover, the Portal Manager allows to retrieve the current context, the current user (plus some other information, such as his/her current security token) at server side. To overcome such limitation and allow developers to test their applications in Eclipse, a file like this one can be used:

# ONLY FOR LOCAL (IDE) DEVELOPMENT - NOT FOR PRODUCTION USE!
# change the properties with your user data and desired scope / token
# Author: Massimiliano Assante, CNR-ISTI
 
# a development user 
user.username=test.user
user.name=aTestName
user.lastname=aTestLastName
user.email=testing.user@gcube-system.org
 
# a development scope (the scope must be bound to the token below)
development.scope=/gcube/devsec/devVRE
 
# a valid user token on the (above) development scope.
# you can obtain it by registering on one development VRE and using Token Generator portlet
user.token= ....

The name of the file must be gcube-dev-context.properties, and must be placed under the CATALINA_HOME system variable. The PortalManager will recognize if the application is running on a real or fake portal and, in the latter case, will retrieve and use the information written in this file.

1. ↑ Liferay is the portal technology adopted in the D4Science Infrastructure which is built upon the gCube software
2. ↑ More information about the PortalManager are reported here
3. ↑ More information about the UserManagement library are reported here