I've run into a problem with this in OUR implementation (yours is fine). We add a couple of fields to the security token (OurBlobCrypterSecurityToken). Thus I really need to cast to MY implementation to retrieve those values. But I can't cast the proxy. I don't want to add the getters to the base SecurityContext interface. I'm actually thinking I might need to use reflection to get to the getters I need. Yuck.
doug On 9/20/11 12:09 PM, "Stanton Sievers" <[email protected]> wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/1981/ > ----------------------------------------------------------- > > 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/ap > ache/shindig/auth/BlobCrypterSecurityTokenCodec.java 1173205 > > http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/a > pache/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 >
