[SHINDIG-1626] BlobCrypterSecurityTokenCodec tries to use "instanceof" when the parameter is a Proxied object

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.5.0-beta1
• Fix Version/s: 2.5.0-beta1
• Component/s: Java
• Assignee: Unassigned
• Reporter: Stanton Sievers
• Created: 20/Sep/11 15:59
• Updated: 29/Mar/12 20:58
• Resolved: 22/Sep/11 16:04

Description

When using the default implementation of "secure" security tokens in Shindig, we use BlobCrypterSecurityTokenCodec and BlobCrypterSecurityToken as our SecurityTokenCodec and SecurityToken, respectively. This is all well and good until we try to generate an iframeurl with the security token in it. Security tokens are only added as an iframeurl query parameter when the gadget requires the "security-token" feature, explicitly or implicitly through other requires such as "opensocial".

In short, DefaultIframeUriManager tries to generate the "st" query parameter and we get into BlobCrypterSecurityTokenCodec.encodeToken(SecurityToken) which checks if token instanceof BlobCrypterSecurityToken. This instanceof returns false because BlobCrypterSecurityToken has been Proxied by GadgetsHandlerService.convertAuthContext(AuthContext, String, String). The aforementioned encodeToken method relies on being able to call BlocCrypterSecurityToken.encrypt(), which is not a method that exists on SecurityToken for which the Proxy was created.

The result is that the iframeurl "st" query parameter is templated. That is, we get "...&st="%25st%25"..." for the iframeurl.