[
https://issues.apache.org/jira/browse/SHINDIG-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109629#comment-13109629
]
[email protected] commented on SHINDIG-1626:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1981/
-----------------------------------------------------------
(Updated 2011-09-21 16:28:56.153311)
Review request for shindig and Henry Saputra.
Changes
-------
As promised, a new version that relies on the BlobCrypterSecurityTokenCodec
passing in the BlobCrypter to the BlobCrypterSecurityToken. This allows BCSTC
to call a static encrypt method on BCST instead of relying on instantiating a
BCST itself.
We still have the problem of the AuthContext needing to have the appropriate
getters. I don't see a way around this.
Summary
-------
See the JIRA for a description of the problem:
https://issues.apache.org/jira/browse/SHINDIG-1626
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.
This addresses bug SHINDIG-1626.
https://issues.apache.org/jira/browse/SHINDIG-1626
Diffs (updated)
-----
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/BlobCrypterSecurityToken.java
1173205
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodec.java
1173205
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodecTest.java
1173205
http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/auth/BlobCrypterSecurityTokenTest.java
1173205
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/GadgetsHandlerApi.java
1173205
Diff: https://reviews.apache.org/r/1981/diff
Testing
-------
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.
Any other testing recommendations are welcome. :)
Thanks,
Stanton
> 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
