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