Thursday, September 20th, 2007

Google launches JavaScript API that allows you to write back

Category: Google, JavaScript, Library

I am pretty excited about this one. We have long been able to use a JavaScript API to do read only work on GData feeds from Google. That is all well and good, but sometimes you want to be able to access feeds that require authentication, or be able to write and update data in feeds.

Well, now you can. The GData team has released a GData JavaScript Client Library. The first service available is Google Calendar, and we can hope for more to come.

This cross-domain, secure, access seems similar to Subspace, but it is actually live right now. Having a service such as Google Calendar using this is a great step forward, as you know it has been through a thorough security review.

Authentication happens via AuthSub, and you end up using new APIs such as:

javascript

  1. function logMeIn() {
  2.   scope = "http://www.google.com/calendar/feeds";
  3.   var token = google.accounts.user.login(scope);
  4. }
  5.  
  6. function setupMyService() {
  7.   var myService =
  8.     new google.gdata.calendar.CalendarService('exampleCo-exampleApp-1');
  9.   logMeIn();
  10.   return myService;
  11. }

When google.accounts.user.login(..) occurs, it will send you to Google to authenticate. A best practice is to provide a login button or other user input mechanism to prompt the user to start the login process manually. If, instead, you call google.accounts.user.login() immediately after loading, without waiting for user interaction, then the first thing the user sees on arrival at your page is a Google login page. If the user decides not to log in, then Google does not direct them back to your page; so from the user’s point of view, they tried to visit your page but were sent away and never sent back. This scenario may be confusing and frustrating to users. Note that the example code above does call google.accounts.user.login() immediately after loading, to keep the example simple, but we don’t recommend this approach for real-world client applications.

I am excited about this, as it means that you can write a rich Ajax client that doesn’t need server-side proxies to do these things, which traditional was the only solution. Now the server-less model can grow even more.

I got to sit down with Jun Yang, who worked on this code, and got his take:

Posted by Dion Almaer at 8:27 am
11 Comments

++++-
4 rating from 45 votes

11 Comments »

Comments feed TrackBack URI

Now all we have to do is wait for this sort of thing to become mainstream, and then create a fake Google login page and offer to ‘import your calendar items’ and voila, you have someones Google account.

I’ll make a social website where you can show off your bank account balance, all I need you to do is click this link and enter your username and password. “Easy money!”

Comment by mike — September 20, 2007

If I understood the talk correctly, you have to log in on the -actual- google-page -and- allow the service provider access to your data.

Comment by Tommy Valand — September 20, 2007

Somewhere along the way, we will all realise that you cant endlessly protect people anymore.
You might compare this to the street life in a city, at some point people will have to grow up and take care of themselves.
Developers can’t do that for them in the long run.

Comment by mikael bergkvist — September 20, 2007

By the way, it’s a smalltimer, sure, but still, the http://www.widgetplus.com framework also allows read/write data and the managing/creation of new accounts.

Comment by mikael bergkvist — September 20, 2007

There seems to be a small error in the post: the code does not immediately log in, instead it logs you in when calling the logMeIn-function.
As for mikes comment: this looks similar to the OpenID phishing problem, I hope we get this fixed soon.

Comment by Christian Decker — September 20, 2007

i believe you could DIY all this with XHR already. rather than improve the client libraries, i would have much preferred it if Google Data protocol now permitted JSON for submitting/posting/updating data.

Comment by rektide — September 20, 2007

No doubt google always works for the best for their users. Google shows in their all the project the different approach normally which is not using anywhere. I have not even experience this but I am going to check this and hope this will be a great as well.

Comment by DESIGNEXPANSE.COM — September 20, 2007

> “I am excited about this, as it means that you can write a rich Ajax client that doesn’t need server-side proxies to do these things”

Someone is missing the usual point of server-side proxies, which is to control access to stateful services. This is the equivalent of opening your database ports directly to the world. There will always be stateless server-side proxies to data; it’s the best way to scale connectivity, no matter what anyone develops on the client side.

Comment by Travis Wilson — September 22, 2007

That is great, but makes it a bit complicated when you take into account all the API conditions a developer will have to figure out to get a simple task done.

There is a service, AppPad http://AppPad.com, which provides a much simpler way to store data without hosting/databases. (build & host apps in Javascript)

Comment by sav74sac — March 1, 2008

hi

i try to run this code but i got the error message like

” google.accounts is undefined ” please help me to authenticate the google

my code is :

logMeIn();
function logMeIn() {
scope = “http://www.google.com/calendar/feeds”;
var token = google.accounts.user.login(scope);
alert(token);

}

Comment by aumkii — July 31, 2009

hi

i try to run this code but i got the error message like

” google.accounts is undefined ” please help me to authenticate the google

my code is :

logMeIn();
function logMeIn() {
scope = “http://www.google.com/calendar/feeds”;
var token = google.accounts.user.login(scope);
alert(token);

}

please email me the Solution i need to authenticate the fiance Google finance API

my id : damu.be@gmail.com

Comment by aumkii — July 31, 2009

Leave a comment

You must be logged in to post a comment.