> On 2011-09-20 22:07:14, Henry Saputra wrote: > > 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.
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: > > ----------------------------------------------------------- > 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 > >
