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:
- Fork from shindig-2.5.1.Final
- All commits we've pushed for fixing bugs in gatein-shindig can now be removed --> They're all fixed already in Shindig 2.5.1
- There is a bug in the apache shindig-2.5.1.Final, here is the fix (Add dependency between core.util.onload and core.util.event feature · ae6a2b1 · exoportal/gatein-shindig · GitHub)
- Use gatein-dep 1.4.0.Final for dependency management
- All other commits are for making changes in pom.xml for release purpose
- 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>
- Changes on security token generator classes and container config loader of GateIn, there are new propertie in shindig.properties and container.js. For details, pls look at this commit https://github.com/exoportal/gatein-portal/commit/29470ad884986660dedc0177c37f0896ecb10bf3#diff-4
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" : {
"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"
}
}
- For testing, there is a sample OAuth2 gadget that access to google api: https://github.com/apache/shindig/blob/shindig-project-2.5.1/content/gadgets/oauth2/oauth2_google.xml
- 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
- More implementation details in here https://github.com/exoportal/gatein-portal/commit/e88f5877a199344a964b3dfab1fab4f16c91374f
Comments