Hi Mark, It's possible that some of the requests were being cached by our proxy, thus eliminating the call to your server? I'd expect that authenticated/signed requests wouldn't be cached, but it would be something to investigate.
Regarding manual registration, that appears to be a requirement that we recently lifted. Thanks for pointing it out. To address the bad news, many of the problems you've encountered are due to the fact that iGoogle is in a transition phase. If there were a single, unified set of docs, most of the confusion about what works and what doesn't would simply go away. Unfortunately, we're left in a situation where some developers are writing gadgets to target production and some are writing gadgets to use new features. I can't really promise it will get better until gadgets.* launches in production. And, while I'm hopeful to have a timeline for you soon, the one we had earlier was abandoned, and so there is hesitation to make a new one public. Best, Dan On Jan 15, 4:32 pm, Mark Paine <[email protected]> wrote: > Dan, > > The good news: > It's working now. I dug deep into the gadgets.io.* javascript, figured > out that there was nothing there to inhibit what I want to do, and > then just dug deeper into my Apache logs and found that *some* (but > not all) of the sandbox page reloads were indeed causing makeRequest() > to hit my server. > > Now, just so you know for future reference: > From that URL you pointed me to: > > > A Note to OAuth Service Providers > > > If you want to help your development community avoid this manual > > registration step, you can instead > > augment your OAuth configuration to accept digital signatures directly from > > iGoogle. > > I don't want to have to do this manual registration step, nor does it > appear that I have to. > > And now some bad news: > The whole gadget development experience is, well, utterly awful. The > documentation is helter-skelter. There are broken links all over your > site. Some documents suggest a Content type of "html" while others > recommend "url". GGE is terrible, and shouldn't be allowed to exist on > a sandbox page if it doesn't support all of the sandbox features. The > OAuth "tricks" page doesn't really have any tricks at all... it just > has random musings and notes, but nothing all that valuable. It's > completely unclear what features are currently supported in the > sandbox, reducing developers to trial and error. It's also completely > unclear what kind of ballpark timeline you have for putting sandbox > features onto iGoogle, if ever. > > It would be nice to see the root cause of a lot of questions addressed > with better documentation. I suspect that you would have a lot more > gadget development activity if the documentation problems were > addressed. > > Respectfully, > -Mark > > On Jan 15, 2:35 pm, "Dan (Google Employee)" <[email protected]> > wrote: > > > Hi Mark, > > > Have you read/followed the instructions > > here:http://code.google.com/apis/gadgets/docs/oauth.html?Ibelieve one of > > the steps is to register the service provider with Google. It's likely > > it will not work without that step. > > > Best, > > Dan > > > On Jan 15, 9:39 am, Mark Paine <[email protected]> wrote: > > > > Hi Dan, > > > > Quick clarification... > > > > Is 3-legged auth supported in the sandbox for 3rd party providers? > > > > If so, any ideas why a gadget which loads without error in the > > > sandbox, with code along these lines would never hit my provider > > > server with a request? > > > > <Require feature="opensocial-0.8" /> > > > <OAuth> > > > <Service name="myprovider"> > > > <Access url="https://www.myprovidername.com/oauth/access_token/"; > > > method="GET" /> > > > <Request url="https://www.myprovidername.com/oauth/request_token/? > > > scope=http://www.myprovidername.com/oauth/"; method="GET" /> > > > <Authorization url="https://www.myprovidername.com/oauth/ > > > authorize/?oauth_callback=http://oauth.gmodules.com/gadgets/ > > > oauthcallback" /> > > > </Service> > > > </OAuth> > > > ... > > > function fetchData() { > > > var params = {}; > > > url = "http://www.myprovidername.com/oauth/photo/?alt=json";; > > > params[gadgets.io.RequestParameters.CONTENT_TYPE] = > > > gadgets.io.ContentType.JSON; > > > params[gadgets.io.RequestParameters.AUTHORIZATION] = > > > gadgets.io.AuthorizationType.OAUTH; > > > params[gadgets.io.RequestParameters.OAUTH_SERVICE_NAME] = > > > "myprovider"; > > > params[gadgets.io.RequestParameters.OAUTH_USE_TOKEN] = "always"; > > > params[gadgets.io.RequestParameters.METHOD] = > > > gadgets.io.MethodType.GET; > > > > gadgets.io.makeRequest(url, function (response) { > > > ... > > > > Thanks, > > > -Mark > > > > On Jan 12, 10:43 am, "Dan (Google Employee)" <[email protected]> > > > wrote: > > > > > Hi Guy, > > > > > The sandbox does support 3-leggedOAuththrough the makeRequest > > > > function, as outlined > > > > here:http://code.google.com/apis/gadgets/docs/oauth.html. > > > > However, 3-leggedOAuthas part of the REST/RPC protocol/client > > > > libraries is not yet supported on iGoogle. > > > > > Best, > > > > Dan > > > > > On Jan 11, 2:37 am, Guy Rutenberg <[email protected]> wrote: > > > > > > Hi, > > > > > > I'm working on an app that requires mapping a user to an iGoogle's > > > > > owner id (in the sandbox).OAuth's3-legged authentication seems to be > > > > > the most appropriate way to implement it. > > > > > > However, as I understand iGoogle doesn't support it yet. Does anybody > > > > > knows if and when iGoogle will support the 3-legged authentication > > > > > protocol? > > > > > > Thanks, > > > > > > Guy Rutenberg --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "iGoogle Developer Forum" 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/Google-Gadgets-API?hl=en -~----------~----~----~----~------~----~------~--~---
