Re: Security in Shindig

[Paul Lindner <li...@inuus.com>]

A mobile client could register a 'stub' gadget spec to the SNS to gain
access.  In fact the default view could contain a download link for the
mobile app or other useful functionality.

On Wed, Feb 24, 2010 at 8:58 AM, Nicola Ghirardi
<gh...@gmail.com>wrote:

> Another use case is use of rest api without any gadget. am i wrong? A
> mobile client is a good example?
> What happen in this case? How is it possible for a API client to get
> ConsumerKey and CONSUMER_SECRET and CONSUMER_KEY?
> I think the container SNS should think about it, but where/how
> shinding is checking that keys?
> Thanks for the help.
>
>
>
> >Shindig provides 3 different ways to verify whether a incoming social data
> >request is valid:
> >1)
> >2)
> >3) validate the "OAuth token", through "OAuthAuthentication".
>  >   For short, Shindig supports OAuth protocol thus the requester could
> >integrate the OAuth authorization flow to generate a valid OAuth access
> >token, and uses this token to issue the request.
> >
> >For the way c, basically it happens on the gadget rendering stage (<iframe
> >src="http://shindig/ifr?...").  In that stage a st token will be appended
> to
> >the rendering request URL.  Thus the authentication follows the #2,
> >URLParameterAuthentication flow.
>