Hi everyone, 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. Has anyone been able to get this use case working? Any ideas on how it can be fixed? I'm not an expert on how Java's Proxies work but this seems critically blocked due to the use of a Proxy. One solution would be to add an "encrypt" method to the SecurityToken interface but that seems like cheating. :) Thanks, -Stanton
