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



Reply via email to