BlobCrypterSecurityTokenCodec tries to use "instanceof" when the parameter is a
Proxied object
----------------------------------------------------------------------------------------------
Key: SHINDIG-1626
URL: https://issues.apache.org/jira/browse/SHINDIG-1626
Project: Shindig
Issue Type: Bug
Components: Java
Affects Versions: 3.0.0
Reporter: Stanton Sievers
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
