hangoutiframer.appspot.com provides a simple interface for you to automatically generate an .xml file that wraps an HTML file and puts it in an iframe in your Hangout. It's convenient for developers who have AJAX or Flash in their Hangout Apps, as it means your app is running on *your* website, not googleusercontent.com.
One of the new features in Hangout Apps is providing support for OAuth 2.0 access tokens. Once you create a Client ID for your Hangout App (a required step to release the app in public), users must give permission to your app to run. You can retrieve an access token from the gadget without further permissions or authentication.
Now, hangoutiframer can retrieve your access token, too! It also now supports appending data to the hangout URL for startup.
Sample Code
Try out our sample app!http://plus.google.com/hangouts/_?gid=60353041584
You can find the code and instructions here:
http://code.google.com/p/hangout-experiments/source/browse/#git%2Foauth%2Fiframe
Passing data into a hangout iframer app
With today's upgrade, you can also pass in data from a startup URL, like so:https://plus.google.com/hangouts/_?gid=60353041584&gd=SomeStartupData
and it will appear in your iframed Hangout app as a parameter to the iframe's URI. Give it a try!
Using OAuth 2.0 access tokens
Authentication and OAuth 2.0 can be complicated. For many apps, especially apps that have all of their state stored in the Hangouts API shared state, you probably don't need to worry about this. However, if you need to be sure someone is who they say they are, read on! You can (and should!) find out more about how OAuth 2.0 works at the Google OAuth 2.0 documentation.A big reason to use an OAuth 2.0 access token in your hangout is to make verified actions on your server. That is, when a given participant makes some irreversible action, you want to know that it was really this participant, authorized for this app, to make that action.
One example might be looking at your cards in a card game---you don't want to put your cards in the Hangout shared state or a clever hacker can just look at them using the Chrome Javascript debugger! Instead, you will want each Hangout participant to talk to a server, and you want your server to be sure it's really that participant talking, not someone else in the Hangout who happens to know about this game. This is what an access token can provide.
If participants wants to see their cards, their running Hangout App can pass the OAuth 2.0 token to the server along with a request to be verified. Your server then can verify that it's them acting on behalf of your app using the validate token endpoint. Once the server has validated the token, it doesn't need to again for that particular Hangout instance. Your server then should send the client an app-specific authentication tokens for conversations between the Hangout App and your server.
The TokenInfo endpoint will return the valid scopes, the users G+ id, and the application that runs it. As a technical note, the 'audience' field of that token will contain a modified application id as it is running inside a gadget. The first part of the audience field should contain your app ID.
The tokens will expire, usually in about an hour. Right now, hangoutiframer doesn't support refreshing your access token when it expires, so it's good to validate the token early on in the client's relationship to the server.
