>-----Original Message----- >From: daviesd [mailto:davi...@oclc.org] >Sent: Tuesday, November 22, 2011 10:01 AM >To: dev@shindig.apache.org >Subject: Re: Oauth 2 consumer implementation > >So how does a gadget know what service name to use since every container >could define facebook differently.
The following is based on my understanding from oauth 1.0 and I'm assuming it still applies to oauth 2.0 -- but I haven't spent much time looking at oauth 2.0 yet so hopefully someone will correct me if any of this is no longer applicable... I believe the gadget author needs to coordinate registration of their oauth details with each container they want to run their gadget in -- and part of that coordination process is for the gadget to define what service name to register the details under. It's up to the gadget developer to coordinate with the service provider (like facebook) on getting the oauth details in the first place though. As Ryan mentioned containers are free to define the "coordination" process any way they choose, but I think a common strategy might be for the gadget authors to register the details themselves as part of the gadget registration process. That's what we've done with our internal container implementation and what I believe we're planning to do in Apache Rave. I just took a quick peruse through the opensocial 2.0 specification and it seems at a quick glance that all of what I've said above still applies, although it does seem that there is another case where the container can choose to register container-wide oauth details for a service provider -- I haven't seen that case used personally though so I can't really say too much more about that. I assume if a container does that though they would need to advertise that fact to gadget developers and provide them all the details they would need to take advantage of it. That would seem to imply though that users would just be authorizing the container as a whole though as opposed to a specific gadget which doesn't seem like what you'd want -- unless the specific gadget is communicated in the request somehow... Maybe that's part of what oauth 2.0 adds? Hopefully someone who knows more about this specific use case can comment further. One other thing worth pointing out is that the above all applies to three-legged oauth, but opensocial also supports signed fetch (aka two-legged oauth) which is kind of nice for when you want to setup an explicit trust relationship with an external provider where you don't actually need the user to approve access to their resources. >doug > >On 11/21/11 2:34 PM, "Ryan J Baxter" <rjbax...@us.ibm.com> wrote: > >> Mike, usually the provider information is configured before hand. Your >> container could choose to allow gadget developers to register the provider >> information, but this is outside the scope of Shindig and the OpenSocial >> spec. >> >> -Ryan >> >> Email: rjbax...@us.ibm.com >> Phone: 978-899-3041 >> developerWorks Profile >> >> >> >> From: Michael Matthews <matth...@oclc.org> >> To: <dev@shindig.apache.org>, >> Date: 11/21/2011 02:27 PM >> Subject: Oauth 2 consumer implementation >> >> >> >> My organization is investigating implementing a "production-ready" version >> of Shindig's OAuth2 Consumer implementation. After reviewing the wiki at >> opensocial.org (in particular >> >http://docs.opensocial.org/display/OSD/OAuth+2.0+Consumer+Implementat >ion+in+ >> >> Apache+Shindig) and studying the code to Shindig's sample OAuth2 >Consumer >> implementation, it appears that we need to implement our own version of >> the >> OAuth2PersistenceModule (e.g. use a database instead of oauth2.json). >> >> Some of our remaining questions center around when/how some of the >OAuth2 >> related data is persisted. >> >> Presumably, a gadget developer will declare what OAuth2 services they use >> in >> their gadget.xml like so: >> >> <OAuth2> >> <Service name="googleAPI_test" >scope="https://www.google.com/m8/feeds/";> >> <Authorization >> url="https://accounts.google.com/o/oauth2/auth";></Authorization> >> <Token url="https://accounts.google.com/o/oauth2/token";></Token> >> </Service> >> </OAuth2> >> >> They will then invoke this service using gadgets.io.makeRequest(). >> >> Is the expectation that the Shindig container have this OAuth2 provider >> pre-configured before the gadget is rendered? Is it possible to register >> a >> provider (in this case Google) at runtime? >> >> Thanks >> Mike >> >> >> >
