Thanks for the clarification. I'd assumed we needed an Oauth SP for the api server. I'll probably look to pulling in the oauth.net sample code for the time being. I'm familiar with OAuth and how it's used in shindig. Brian's post from last Friday being a good summary.
What I wasn't so sure about was the use case overlap of the Gadget Token and the Oauth token. If you search for 'token' in the gadgets project, it's hard to sort out the differences between the oauth tokens and the gadget tokens. Sometimes the gadget tokens are referred to as 'auth tokens' and it's all rather confusing if you're just coming upon it. Are there docs that explain what tokens are used when? For example OAuthStore.TokenKey seems to have many of the same fields as the GadgetToken. I'm pretty sure they don't overlap but it is confusing from the perspective of the api server, which to use. Did I just miss the emails where all this was explained? I wasn't paying total attention at the time. Anyone have a preference for which is implemented first? I'd lean toward Oauth support since that's more natural for the api server and the GadgetDataServer already handles the one kind of token. davep On Wed, Apr 30, 2008 at 2:56 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > On Wed, Apr 30, 2008 at 2:22 AM, Cassie <[EMAIL PROTECTED]> wrote: > > > This should be fairly straightforward as you can just look at what the > > current json social code is doing. In GadgetDataServlet it grabs the > > security token "st" from the url, parses it and then passes the gadget > > token > > around to all of the interfaces and such. > > > > You should be able to do exactly the same thing. > > This does mean that users will have to pass in st=xxx and I don't know how > > that works when third party servers call you... it'll be easy for my js > > restful code though :) > > > That's only half of the story (the opensocial-0.x feature using the RESTful > API). The other half is the external usage of the APIs, which is based on > OAuth. > > Right now, OAuth is only used for calls from container -> service provider. > What you need is for Shindig to also be a RESTful service provider. It was > never clear to me how this fit into the spec, but I'm going to assume that > it's already been covered and we don't have t othink about it. > > I assume we can reuse the container -> service provider code for the most > part. We still need to migrate org.apache.shindig.gadgets.oauth from gadgets > to common, though. > > > > > > > > I hope that helps. > > > > - Cassie > > > > > > On Tue, Apr 29, 2008 at 11:16 PM, David Primmer <[EMAIL PROTECTED]> > > wrote: > > > > > I'm curious how I can start to implement the handling of the tokens > > > used in opensocial for the rest server. Do we have social token and > > > oauth token? Maybe Brian or Louis can chime in here? > > > > > > Can I get a pointer to how to get going? Our server framework has > > > methods for getting the user and other parameters from the context and > > > we'd like to use this to help with the processing of the requests that > > > take the auth context into account. I'm assuming we'll share what's > > > already in use. > > > > > > davep > > > > > >
