[
https://issues.apache.org/jira/browse/SHINDIG-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109123#comment-13109123
]
[email protected] commented on SHINDIG-1626:
--------------------------------------------------------
bq. On 2011-09-20 22:07:14, Henry Saputra wrote:
bq. > Yeah its getting hard to maintain. The only reason we want to cast it to
BlobCrypterSecurityToken is to call BlobCrypterSecurityToken.encrypt.
bq. >
bq. > 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.
I'm not sure that moving that logic out would solve the problem. We still need
the values map to pass to the crypter. That values map is currently
constructed in the BlobCrypterSecurityToken using the local fields. We still
can't get all of those values because we're proxied through an AuthContext
interface.
I do like the idea of moving the knowledge of the crypter out of the
BlobCrypterSecurityToken so the BlobCrypterSecurityTokenCodec doesn't have to
construct the BlobCrypterSecurityToken. Regardless, I think the data getters
in SecurityToken are going to need to also be added to AuthContext.
I'll post a patch tomorrow that illustrates this idea if it doesn't quite make
sense.
- Stanton
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1981/#review1981
-----------------------------------------------------------
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
