Yeah, I was thinking about exposing the type of token used based on container configuration rather than using class name to identify what type of authentication used.
It would be either new SecurityToken API or extend the AuthenticationMode to add encrypt or plain for the token url parameter. So the crypter can check for the type, including the proxy token generated from bean delegator, rather than check for instanceof the token. - Henry On Mon, Sep 19, 2011 at 11:51 AM, Stanton Sievers <[email protected]> wrote: > 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 >>> >>> >> >> > > > > >
