On Fri, Jul 18, 2008 at 10:02 AM, Chris Chabot <[EMAIL PROTECTED]> wrote:
> While working on the PHP version of shindig, i actually went the anonymous > token route. > > What i did is construct a standard SecurityToken object, however with > viewer = owner = app id = 0, which is the magic 'anonymous' id. I thought > this makes sense since it's up to the SNS how to deal with anonymous data > access, some will allow full access to everything, some only to 'public > profiles', some only to a subset of the available information and some will > want to completely disallow it.. by passing it as an anonymous token, the > SNS's service layer can decide how to deal with it ... which seemed the > right solution to me. > > If you pick another solution on the java side let me know so i can adjust > accordingly :) As long as the token is properly formed, it should work fine in the Java code as well. > > -- Chris > > > On Jul 18, 2008, at 4:38 PM, Paul Lindner wrote: > > >> I did just notice that a security token is now required for all REST >> operations. If I modify my implementation of SecurityTokenDecoder I can >> construct an 'anonymous' token and return that when a token is not presented >> (this would use a magic userid deemed 'anonymous')... Or we could catch the >> exception and continue processing in contexts where anonymous retrieval >> makes sense.... >> > >
