-----------------------------------------------------------
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:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/1981/
> -----------------------------------------------------------
> 
> (Updated 2011-09-20 16:35:32)
> 
> 
> Review request for shindig and Henry Saputra.
> 
> 
> 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
> -----
> 
>   
> 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/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
> 
>

Reply via email to