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 <[email protected]>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. >
