[
https://issues.apache.org/jira/browse/SHINDIG-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109023#comment-13109023
]
[email protected] commented on SHINDIG-1626:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1981/#review1981
-----------------------------------------------------------
Yeah its getting hard to maintain. The only reason we want to cast it to
BlobCrypterSecurityToken is to call BlobCrypterSecurityToken.encrypt.
I think we should move out the encrypt and decrypt business out from token and
delegate it to BlobCrypterSecurityTokenCodec. So BlobCrypterSecurityToken does
not contain crypter at all.
- Henry
On 2011-09-20 16:35:32, Stanton Sievers wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/1981/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-09-20 16:35:32)
bq.
bq.
bq. Review request for shindig and Henry Saputra.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. See the JIRA for a description of the problem:
https://issues.apache.org/jira/browse/SHINDIG-1626
bq.
bq. This fix is based off a fix Doug Davies implemented with some changes
around the parameter checking in BlobCrypterSecurityToken.encodeToken. The
check is sufficient because DefaultSecurityTokenCodec creates the correct
SecurityTokenCode (Basic or Blob) depending on the container config values of
"insecure" or "secure", respectively. We should never get into this code if
we're not using a secure configuration; therefore, an authentication mode of
SECURITY_TOKEN_URL_PARAMETER implies that we have a BlobCrypterSecurityToken
and not some other token, such as Anonymous.
bq.
bq.
bq. This addresses bug SHINDIG-1626.
bq. https://issues.apache.org/jira/browse/SHINDIG-1626
bq.
bq.
bq. Diffs
bq. -----
bq.
bq.
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodec.java
1173205
bq.
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/GadgetsHandlerApi.java
1173205
bq.
bq. Diff: https://reviews.apache.org/r/1981/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested with a sample gadget that utilizes the osapi feature to print the
viewer's name in a secure configuration. The security token is encoded
properly in the modified code.
bq.
bq. Any other testing recommendations are welcome. :)
bq.
bq.
bq. Thanks,
bq.
bq. Stanton
bq.
bq.
> 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
