Version 9

    Currently we are using a forked shindig 2.0.2 at https://github.com/gatein/gatein-shindig

     

    Shindig 2.5.1

    • Released on 2014-03-04 with a lot of bug fixes / new features Shindig-Issues
    • All bug fixes in gatein-shindig are in this shindig versions, so after upgrading, we can remove commits on our forked gatein-shindig
    • There are new features added: OAuth2, ActivityStream support, opensocial 2.5 implementation and some others (details are in shindig jira issues)

     

    GateIn Shindig

    - Working branch:

    exoportal/gatein-shindig at upgrade-shindig-2.5.1 · GitHub

    - Done:

    - Impacts:

    • We have 2 projects to help integrating shindig into GateIn: gadget-core and gadget-server. We'll need to migrate those projects to work with shindig 2.5.1
    • Deprecated opensocial apis that are older than 0.9 has been removed, any gadgets that use those social-api will need to migrate there code
    • Shindig 2.5.1 use Closure compiler and lazy load js features, this make first time request take longer for loading JS (we'll need to increase JS loader timeout)
    • Due to SHINDIG-1540 --> message bundle'll not be trimmed anymore, any gadget that use bundle in there code should be reviewed
    • There are changes in shindig configuration loading machanism, and currently we're overriding some guice modules for loading container.js, some minor changes on converters and security token classes --> details in the next part: upgrading gatein portal

     

    GateIn Portal

    - Working branch:

    exoportal/gatein-portal at upgrade-shindig-2.5.1 · GitHub

    - Done:

    • New dependencies version:

         <dependency>

           <groupId>com.google.guava</groupId>

           <artifactId>guava</artifactId>

           <version>14.0.1</version>

         </dependency>

         <dependency>

           <groupId>org.apache.commons</groupId>

           <artifactId>commons-lang3</artifactId>

           <version>3.1</version>

         </dependency>

         <dependency>

           <groupId>net.sf.ehcache</groupId>

           <artifactId>ehcache-core</artifactId>

           <version>2.5.2</version>

         </dependency>

         <dependency>

           <groupId>args4j</groupId>

           <artifactId>args4j</artifactId>

           <version>2.0.16</version>

         </dependency>

         <dependency>

           <groupId>caja</groupId>

           <artifactId>caja</artifactId>

           <version>r5054</version>

         </dependency>

         <dependency>

           <groupId>com.google.javascript</groupId>

           <artifactId>closure-compiler</artifactId>

           <version>v20131014</version>

         </dependency>

    Gadget Administration

    This feature allow to

    • Remove the existing blacklist functionality in Shindig which currently is enabled by pointing Shindig to a text file with a list of gadgets to blacklist. The new functionality uses a whitelist instead of a blacklist and is indexed on a per container basis. Meaning an admin could whitelist some gadgets in one container but not another
    • Add the ability for administrators to specify which features are allowed and denied for a specific gadget in a specific container. This information is checked in two places, when the metadata request is made and when the gadget is rendered
    • Add the ability for containers to secure RPC requests made by gadgets

    Configuration:

    - eXoGadgetServer.war!/config/gadget-admin.json

    //By default, enable all gadgets and all features

    {

      "portal" : {

        "gadgets" : {

          "*" : {

            "features" : {

              "names" : [],

              "type" : "blacklist"

            }

          }     

        }

      }

    }

    - eXoGadgetServer.war!/containers/default/container.js

    // Enables/Disables feature administration

    //off by default

    "gadgets.admin.enableFeatureAdministration" : false

     

    // Enables whitelist checks

    //off by default

    "gadgets.admin.enableGadgetWhitelist" : false

     

    Whitelist checking:

    • Each gadget need to be listed in the gadget-admin.json, if not, it's considered blacklist and can't be rendered

    Feature checking:

    • Admin can make a list of blacklist or whitelist features in gadget-admin.json
    • If a gadget tried to use any other features besides the ones listed the gadget will not render.  (This would only be true for required features, if a gadget requested an optional feature that was denied the gadget would still be allowed to load but the javascript for that feature would not be provided to the gadget.)  In fact if that container requests the metadata for this gadget the metadata request will fail because the server figures out if the gadget is trying to use any features that it is not allowed to use

    Securing RPC Calls Made To The Container

    • There may be scenarios where you may want to provide RPC services but not declare them in features. In these scenarios you should specify the which gadgets are allowed to use these RPC service ids
    • You can specify this list on a per gadget basis in gadget-admin.json by setting an array of service ids in the additionalServiceIds property. This property should be part of the rpc object for each gadget.

    {

      "default" : {

        "gadgets" : {

          "http://localhost:8080/*" : {

            "features" : {

              "names" : [],

              "type" : "whitelist"

            },

            "rpc" : {

              "additionalServiceIds" : ["rpc_service_1","rpc_service_2"]

            }

          }

        }

      }

    }


    OAuth2

    The Shindig 2.5.1 provide OAuth 2.0-v21 spec compliant server side implementation that supports Authorization Code (3-party) and Client Credentials (2-party) flows

    - Configuration:

    • Default config properties in $TOMCAT/gatein/config/gadgets/shindig.properties (*oauth2 properties with inline comments)
    • Similar to OAuth v1 consumer support in Shindig, Admin have an json config file to add consumer info: eXoGadgetServer.war!/config/oauth2.json. Gadget that make request which require OAuth feature should be declare here in this configuration file. For example:

    "gadgetBindings" : {

          "http://localhost:8080/rest/jcr/repository/portal-system/production/app:gadgets/app:OAuth2/app:data/app:resources/oauth2_google.xml" : {

             "googleAPI" : {

                "clientName"          : "googleApi_client1",

                "allowModuleOverride" : "true"

             }

          }

    }

    "clients" : {

          "googleApi_client1" : {

             "providerName"  : "googleAPI",

             "redirect_uri"  : "http://localhost:8080/eXoGadgetServer/gadgets/oauth2callback",

             "type"          : "confidential",

             "grant_type"    : "code",

             "client_id"     : "530794900275.apps.googleusercontent.com",

             "client_secret" : "GROWyzbjG_HsbJoypD4o5dEa",

             "sharedToken"   : "false"

          }

    }

    - Integration in GateIn:

    • org.exoplatform.portal.gadget.core.oauth2.OAuth2Persister class helps to save Acess and Refresh token to JCR data storage. This class actually act as a bridge between Shindig container runtime (Guice) and eXo Container. It delegate the task to OAuth2TokenService.java
    • org.exoplatform.portal.gadget.core.oauth2.OAuth2TokenService --> interact with JCR services, and help to clean expired tokens
    • New node types for saving Tokens defined in oauth2token-nodetypes.xml. Tokens are saved as JCR nodes in portal-work workspace, with 1 root node:

    /oauth2tokens (tkn:oauth2tokencontainer) --> root node

      + <token> (tkn:oauth2token)

      + <token> (tkn:oauth2token)

       ...

      + <token> (tkn:oauth2token)

    • Each token entity contains attributes map to org.apache.shindig.gadgets.oauth2.OAuth2Token object attributes:

              issuedAt: the time (in milliseconds) when the token was issued

              expiresAt: the time (in milliseconds) when the token expires

              gadgetUri: uri of the gadget the token applies to

              macAlgorithm, macExt, macSecret: the Mac algorithm (http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05)

              properties: Contains any additional properties sent on the token

              scope: scope the token applies to, or "" for no scope

              secret: the token secret (unencrypted or signed)

              serviceName: service's name (in gadget spec) the token applies to        

              tokenType: type of this token e.g. "Bearer"

              type: an Type.ACCESS or Type.REFRESH token

              user: shindig user the token was issued for