Google API: Using gSessionId with AuthSub Part 4

I swear this is a bug. It has to be a bug because it's so ridiculous. If it's not a bug, I hope someone can explain it.

After you finish part 1 and part 2 of logging in using Google's AuthSub. You'll find it's just not enough. Something really weird happens if you attempt to get a list of calendars.

You get an HTTP 302 error. An HTTP 302 error is a redirect error. In a nutshell it's as if they have a cflocation on the first line of their Application.cfc file (translate that into whatever language Google is using). If you automatically redirect on a page that you send a post request to, all the headers are lost. In other words, everything gets screwed up. So here's how to fix it...

Add this code to the GoogleAuthenticate.cfc file:

Are you confused yet? The first question to ask is... What is the token argument? Is it the first token or the second token?

Use the second token. If you really want to understand why, ask and I'll explain.

So all we're doing here is attempting to get a list of calendars. The cfhttpparam header passing in the token tells Google which user's calendars to get. It's going to fail and that's ok, we're expecting it to.

It's going to return an http 302 error. That 302 error will give us a URL to redirect the user to. On the end of the URL is a gSessionId. That's what we want. Strip off the gSessionId and cfreturn it.

This is the last of the Authsub steps you need to do. From here on out every Google API cfhttp request will include an AuthSub token in the header and the url includes: ?gsessionid=#arguments.gsessionid# Here's an example:

These two things tell Google who's data to get. Again, I swear this gSessionId is a bug. In my opinion, there should be no reason you need BOTH an Authorization token AND a sessionId. They're programmatically redundant. But, tough luck, you need them both.

Tomorrow we'll switch gears and start looking at the Google Calendar API itself.

-Steve Nelson