Henry, you're suggesting a new type property that gets used in conjunction with Doug's solution? What would you envision this property being? Would it be the Class of the token or would it be more generic like "secure" or "insecure" to more closely match the container configuration?
Thanks, -Stanton From: Henry Saputra <[email protected]> To: [email protected], Date: 09/19/2011 14:24 Subject: Re: BlobCrypterSecurityTokenCodec relies on instanceof in the face of Proxy Maybe we could add some check to the ST (like adding new type property) instead of the type of the instance. - Henry On Mon, Sep 19, 2011 at 6:35 AM, daviesd <[email protected]> wrote: > Stanton, > > Here¹s my thread questioning the same thing > > http://shindig-dev.markmail.org/search/?q=blobcryptersecuritytoken#query:blo > bcryptersecuritytoken%20order%3Adate-backward+page:1+mid:tvrxdvi4vsdaxbep+st > ate:results > > Here¹s what I ended up doing > > /** > * Overridden to work around casting exception > * See: http://shindig-dev.markmail.org/message/7r62z2ogkd4ad6pf > */ > public String encodeToken(SecurityToken token) throws > SecurityTokenException { > > if ((token instanceof AnonymousSecurityToken)) { > throw new SecurityTokenException("Can only encode > BlogCrypterSecurityTokens"); > } > > BlobCrypter crypter = crypters.get(token.getContainer()); > PlatformBlobCrypterSecurityToken t = new > PlatformBlobCrypterSecurityToken(crypter, token.getContainer(), > token.getDomain()); > t.setOwnerId(token.getOwnerId()); > t.setViewerId(token.getViewerId()); > > try { > return t.encrypt(); > } catch (BlobCrypterException e) { > throw new SecurityTokenException(e); > } > } > > I don¹t like the reversal of the instanceof call, but it works in my > implementation. I then recreate the proxied token and encrypt it, since I > can¹t cast it. I¹m sure there is a better approach. > > doug > > > > On 9/16/11 5:46 PM, "Stanton Sievers" <[email protected]> wrote: > >> Hi everyone, >> >> 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. >> >> Has anyone been able to get this use case working? Any ideas on how it >> can be fixed? I'm not an expert on how Java's Proxies work but this seems >> critically blocked due to the use of a Proxy. One solution would be to >> add an "encrypt" method to the SecurityToken interface but that seems like >> cheating. :) >> >> Thanks, >> -Stanton >> >> > >
