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 >> >> > >
