Sounds good to me!
If there's no strong objections in the next 24 hours or so i'll go
implement it on the php side.
-- Chris
On Jul 18, 2008, at 11:02 PM, Paul Lindner wrote:
Okay, this is similar to my implementation...
I'd suggest then that we add an isAnonymous() method to the
SecurityToken interface.
Then I can replace code that looks like this:
if (token.getUserId() == ANON_UID)
with this:
if (token.isAnonymous())
I'd also make the default SecurityToken implementation throw an
InvalidArgument exception if you tried to access the ownerId/
viewerId/appId when using an anonymous token.
On Jul 18, 2008, at 10:02 AM, Chris Chabot 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 :)
-- 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....
Paul Lindner
[EMAIL PROTECTED]
