Unfortunately, to access this new field from my gadget token I'm gonna need Stanton's latest fix, unfortunately this means reintroducing the metadata bug I reported. CATCH-22. Argh! Hopefully both can be fixed. Still haven't tracked down the metadata issue other than the osapi change made last week.
doug On 9/21/11 2:19 PM, "Henry Saputra" <[email protected]> wrote: > Ah cool, I am not aware about the field. Thanks Stanton. > > - Henry > > On Wed, Sep 21, 2011 at 7:26 AM, Stanton Sievers <[email protected]> wrote: >> Hi Henry and Doug, >> >> Is this not the purpose of SecurityToken.getTrustedJson()? ?It seems to >> just be some arbitrary value you can stick in the token. ?If this is not >> the purpose of the trusted json, do you know what is? >> >> Thanks, >> -Stanton >> >> >> >> From: ? Henry Saputra <[email protected]> >> To: ? ? [email protected], >> Date: ? 09/21/2011 10:03 >> Subject: ? ? ? ?Re: Adding fields to security context v.s. overloading >> viewerId >> >> >> >> Hi Doug, >> >> We have our own security token but havent moved to common container or >> use the new Gadgets metadata APIs so didnt have this problem ... yet >> =) >> >> I am thinking about adding a common property to the SecurityToken >> interface itself to support fields extension like this. >> >> Let me know if you want to take a stab at it otherwise I could propose >> something later today. >> >> - Henry >> >> On Wed, Sep 21, 2011 at 6:38 AM, daviesd <[email protected]> wrote: >>> Yesterday I sent a message to the listserv describing what we have done >> with >>> our SecurityToken implementation. ?We¹ve extended SecurityToken and >> created >>> OurBlobCrypterSecurityToken. ?It has 1 new field that is a complex >> structure >>> (stored as json). ?This was not added to the SecurityToken interface, >> but >>> only to our class and when we need access to these values I was casting >> the >>> object. >>> >>> With the recent issue in encodeToken with it using the proxy, I don¹t >> have >>> access to copy this over during the gadget iframe security token >> generation. >>> In fact, I¹m not even sure at the higher level ( >>> >> org.apache.shindig.gadgets.servlet.GadgetsHandlerService.convertAuthContext >>> ) that it will copy the container security token fields over to the >> gadget >>> one correctly with this new field. >>> >>> So my question is, how are people extending the security token? ?This >> new >>> field I added is additional info we need (security privileges and some >> group >>> information) that is associated with the viewerId. ?Should I really just >>> overload viewerId with this json object and then whenever I use viewerId >> in >>> my services I would pull the appropriate values out of the json? ?Or is >> the >>> security token really meant to be extended? >>> >>> Help is appreciated. >>> >>> Doug >>> >>> >> >> >> >> >
