Hi The main issue here is the OAUTH stuff.
Any insights/ correctness and assistance about the following (common) opensocial-ouath scenario, would be much much appreciated: (1) a gadget is deployed to a opensocial container - MySpace, iGoogle, Hi5, Linkedin, ... (2) the gadget communicates with the hosting opensocial-container (1) and retrieves the viewer & owner profiles & activities (3) the gadget communicates to OUR Product's Ouath-Restfull services to retrieve and update the viewer/owner activities & profiles (4) the gadget communicates to other oauth-enabled (& not aouth- enabled) service providers (opensocial or not) to retrieve/update profiles/activities like MYSpace, rememberthemilk, ... Some questions: As of my understanding the current gadgets-oauth extensions provides OAuth Proxy, which "OAuths" the gadget against ONE Oauth Provider through Oauth.json. How this (json configuration) should be done, on public opensocila-containers (MySpace, iGoogle, ....)? As of my understanding there is no container which provide the OAuth- Proxy beside Orkut & iGoogle, so is the only path is using "manual SIGNED" requests? As of my understanding consuming services from more than one service provider has to be done through our back-end (see louis answer) as the current opensocial-containers do not provide the means for "multi- server provider registration". is it true?! In general, What's the straight-forward, COMMON and AVAILABLE techniques to accomplish the 1-4 flow above? Specifically: What are your recommendations to implement a opensocial- gadget which accesses OAuth-enable and NOT OAouth-enabled Service providers (Opensocials and not)? I have red the most of specs & threads regarding the Oauth+opensocial and could not conclude the common and right path! Again any directions would be much appreciated. Hertzel On Dec 12, 4:50 am, Louis Ryan <[email protected]> wrote: > Hertzel, > Answers below... > > -Louis > > > > On Thu, Dec 11, 2008 at 7:16 AM, hertzel <[email protected]> wrote: > > > Hi > > > We have investigated a while the OAuth & OpenSocial/Shindig projects, > > actually reviewed every piece of documentation and specification about > > these technologies including design/best practices, installed the open- > > source references (shindig, google-oauth, etc.) > > > We have a "ACTIVITY CENTRIC" product with some social features based > > on J2EE as server-side and Adobe AIR (RIA) as client-side. > > Now, we are intended to socialize our product and would like to get > > your advice and recommendations, before start-coding. > > > (1) Our requirements are as follow: > > (1.1) Exposing our data and services to the community, developers > > (1.2) Developing our opensocial gadgets to be installed on existing > > opensocial networks > > (1.3) providing a new opensocial network based on our current services > > > (2) As of our understanding these requirements' implementations > > should be as following accordingly: > > (2.1) 'RESTify' our services and secure them by GOOGLE-OAUTH SERVER, > > implemented & deployed locally + registration module which provides > > consumer key & secrets to social consumers > > Yes, though I should point out that OAuth is an open standard. You can use > the social-api package from Shindig to get a leg up on building the REST > APIs in Java or you can build them from scratch or use the Java library from > OAuth.net and roll your own. > > > > > (2.2) Developing gadgets based on opensoial-gadgets which consume our > > services from (2.1) - no server is required here beside a web server > > hosting the gadgets' xml > > Yup thats it, you'll want to make sure the communication between the > container and your services are secure. Some containers will require you to > register your application and generate a shared-secret before OAuth signing > is enabled. > > > > > (2.3) Deploying the Shindig (java project) container, enhanced by data > > server (beside xml) > > > (3) Other question: > > (3.1) How could we feed the opensocial activity streams in any > > opensocial network by our activities which have been produced in our > > product by the viewer? > > If the container grants permission for you to do so then you use the REST > API to POST an activity. Containers have different permission models for > their activities but you can rely on the status codes in response to the API > call to figure out what happened. > > > > > (3.2) What's your recommendations about mashup gadgets which provide > > services/data - from our product + other social sites - in the same > > gadget > > As of unclear documentation about implimentation of (google) OAuth > > Servers (for service providers) & Container servers, we would be much > > appreciated to get some advice/directions and best practices beside > > what already published on the web! > > There are a number of ways to do this. Your gadget running in container A > can make calls to your backend which can then call container B for > information. It will also be possible to have container A manage the > credentials for Container B on behalf of your gadget and so your gadget can > make the request without going through your server. See the definition of > the OAuth services in the gadget specification for details on this. An > example is included in the Shindig code. See > oauth.xml<http://svn.apache.org/viewvc/incubator/shindig/trunk/javascript/sampl...> > > > > > Hertzel > > > Hertzel Karbasi Enterprise Architect OPTinity eSolutions, CEO > > [email protected] +972.54.431.431.9 MeadoWare is Coming soon! > > On Dec 12, 6:50 am, "Chris Messina" <[email protected]> wrote: > This group is intended more to discuss the development of the OAuth protocol > rather than anything related to OpenSocial in particular. > I recommend that you try your query on one of the OpenSocial lists: > > http://groups.google.com/group/opensocial-and-gadgets-spec/topics > > ...except that I see that you've already done that, so I'd continue pursuing > this topic there: > > http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thr... > > Chris > > > > On Thu, Dec 11, 2008 at 9:15 AM, Hertzel <[email protected]> wrote: > > > Hi > > > We have investigated a while the OAuth & OpenSocial/Shindig projects, > > actually reviewed every piece of documentation and specification about > > these technologies including design/best practices, installed the open- > > source references (shindig, google-oauth, etc.) > > > We have a "ACTIVITY CENTRIC" product with some social features based > > on J2EE as server-side and Adobe AIR (RIA) as client-side. > > Now, we are intended to socialize our product and would like to get > > your advice and recommendations, before start-coding. > > > (1) Our requirements are as follow: > > (1.1) Exposing our data and services to the community, developers > > (1.2) Developing our opensocial gadgets to be installed on existing > > opensocial networks > > (1.3) providing a new opensocial network based on our current services > > > (2) As of our understanding these requirements' implementations > > should be as following accordingly: > > (2.1) 'RESTify' our services and secure them by GOOGLE-OAUTH SERVER, > > implemented & deployed locally + registration module which provides > > consumer key & secrets to social consumers > > (2.2) Developing gadgets based on opensoial-gadgets which consume our > > services from (2.1) - no server is required here beside a web server > > hosting the gadgets' xml > > (2.3) Deploying the Shindig (java project) container, enhanced by data > > server (beside xml) > > > (3) Other question: > > (3.1) How could we feed the opensocial activity streams in any > > opensocial network by our activities which have been produced in our > > product by the viewer? > > (3.2) What's your recommendations about mashup gadgets which provide > > services/data - from our product + other social sites - in the same > > gadget > > As of unclear documentation about implimentation of (google) OAuth > > Servers (for service providers) & Container servers, we would be much > > appreciated to get some advice/directions and best practices beside > > what already published on the web! > > > Hertzel > > > Hertzel Karbasi Enterprise Architect OPTinity eSolutions, CEO > > [email protected] +972.54.431.431.9 MeadoWare is Coming soon! > > -- > Chris Messina > Citizen-Participant & > Open Technology Advocate-at-Large > factoryjoe.com # diso-project.org > citizenagency.com # vidoop.com > This email is: [ ] bloggable [X] ask first [ ] private --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
