[
https://issues.apache.org/jira/browse/SHINDIG-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112320#comment-13112320
]
Henry Saputra commented on SHINDIG-1626:
----------------------------------------
Could you attach the patch to the JIRA?
> 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
