youtube-eng.blogspot

Deprecating Equine-Frame Embedding

Thursday, March 31, 2011

Although equine-frame embedding of YouTube moving pictures was launched with great huzzabulloo a few short months ago, we regret that we can no longer recommend this horsey practice. While playback quality was smashing, bareback riding quality invariably suffered as a result of the large projector apparatus embedded in the horse’s frame.

As an alternative, we suggest a return to the traditional practice of affixing a portrait of your local constable to the mane of your steed for entertainment on-the-go. When your horse gallops, it will look like the officer is dancing the hully-gully.

Thankfully, progress doesn’t halt with a single setback. We are working closely with various motor-car manufactures, and hope to offer a preview of Model T-frame embedding in time for the next World’s Fair!

—Web-logged by Jeffrey Posnick, who does not suggest embedding anything in a horse that you might want back at a later date.

ClientLogin #FAIL

Wednesday, March 30, 2011

The YouTube API supports a number of authentication schemes—AuthSub, OAuth 1 and 2, and ClientLogin—but it’s that last method, ClientLogin, that is in many ways the most problematic. This blog post will cover some of the ways ClientLogin attempts can fail, and when possible, provide ways of working around those failures.

Before we get into that, though, a bit of a public service announcement: given all the ways that things can go wrong when using ClientLogin, please consider using one of the alternative methods of authentication that the YouTube API supports! AuthSub and in particular OAuth 2 are straightforward to implement and aren’t susceptible to the issues that we’ll cover with ClientLogin. Even if you’re writing a small script for personal use, obtaining one long-lived AuthSub or OAuth 2 token and reusing that for authentication is preferable to hardcoding a login name and password for ClientLogin. And just because your code doesn’t have access to a web browser doesn’t mean that ClientLogin is your only option—this guide covers techniques for using OAuth 2 in such scenarios.

With that out of the way, let’s investigate some failures!

Scenario 1: A user with an unlinked YouTube account attempts ClientLogin.
This scenario won’t actually lead to a failure as of right now, but it will in the near future. As was recently announced on the main YouTube blog, all YouTube accounts must be linked to a Google Account or else logins will start fail—the current plan is to disable logins for unlinked accounts towards the end of April. The only workaround is to have your users link their YouTube account to a Google Account. If they login from a web browser, either at www.youtube.com or using AuthSub/OAuth, they’ll be taken through the steps to link accounts. It’s important to note that while we are requiring linked accounts, we will continue to accept either a YouTube username or a Google Account email address as the Email parameter in the ClientLogin request.

Scenario 2: A user who has enabled to OpenID federated sign-in attempts ClientLogin.
Federerated sign-in using OpenID is a new method of authenticating Google Accounts that correspond to email addresses on specific email providers (currently Yahoo! and AOL). It is currently being offered on an opt-in basis, so for the time being, just because someone’s Google Account is associated with an @yahoo.com or @aol.com address does not mean that they are using Federated sign-in. For the users who have opted-in, ClientLogin will no longer work at all. With Federated sign-in, all login requests need to be processed by the identity provider, and Google’s ClientLogin servers cannot relay the credentials to a third-party server on the user’s behalf. Because AuthSub and both versions of OAuth are web-based, users can log in directly on the identity provider’s site and have that redirect back to Google’s servers to issue the appropriate AuthSub or OAuth token. Migrating off of ClientLogin to AuthSub or OAuth is the only way to provide authentication that works with OpenID accounts.

Scernario 3: A user who has enabled 2-step verification attempts ClientLogin.
This scenario, and the reasons why it will result in a failure, is covered in detail in an earlier blog post. The important takeaway is that a user with 2-step verification enabled needs to generate application-specific passwords for each application that requires ClientLogin, and provide that password instead of their normal Google Account password. Alternatively, using AuthSub or OAuth allows you users to log in using their two factor credentials directly, leading to a better user experience.

Scenario 4: A user encounters a CAPTCHA when attempting ClientLogin.
This is not a new failure scenario, but it’s often overlooked by developers who don’t properly handle it. The ClientLogin documentation includes recommendations for how your application should handle CAPTCHA responses from ClientLogin attempts. If you’re using AuthSub or OAuth, your application does not need to worry about logic for handling CAPTCHAs—it’s taken care of for you by the standard AuthSub and OAuth login process.

This may seem like an exhaustive list of failure scenarios, but as we continue to iterate on the login experience for YouTube and Google Accounts, chances are more “gotchas” will crop up in the future. We’ll do our best to keep our developer community informed, but the best way to future-proof your application is to stop using ClientLogin!

Update: A Google I/O 2011 session borrowed this blog post's title and covered similar material (though not YouTube-specific). Check out the ClientLogin #FAIL session's video embedded below:

—Jeffrey Posnick, YouTube API Team

Best Practices for User Authentication

Thursday, March 17, 2011

(Cross-posted from the Google Code blog.)

By now, many of you have seen our recent announcement regarding 2-step verification for Google Accounts. It’s an optional way of protecting your Google Account from unauthorized access, providing a level of security beyond that of a password alone. The initial announcement did not detail the impact enabling 2-step verification has on programmatic account access from code written against one of Google’s official APIs. We want to go into some more detail regarding the implications of 2-step verification on various authentication (and authorization) techniques, and offer best practices that you as a developer should follow.

There are three forms of authentication supported by almost all of Google’s APIs. AuthSub andOAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.

If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.

ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an HTTP 403 error response from our servers with the following in error included in the response body:

Error=BadAuthentication Info=InvalidSecondFactor

There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.

The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.

While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.

By Jeffrey Posnick, Google Developer Relations

HTTPS Support for YouTube Embeds

Wednesday, February 9, 2011

HTTPS, the secure counterpart to HTTP, wraps a layer of encryption around the information traveling between your computer and a web server. YouTube already uses HTTPS to encrypt sensitive data during the account login process. Now we’re planning a gradual expansion of HTTPS across other aspects of the site. The first place you may see HTTPS YouTube URLs is in our various embed codes, all of which currently support HTTPS in addition to the standard HTTP. Anyone can try HTTPS with YouTube embeds today—simply change the protocol portion of the URL from http to https. For example, http://www.youtube.com/embed/Zhawgd0REhA becomes https://www.youtube.com/embed/Zhawgd0REhA. This applies to URLs found in our newer <iframe> embeds as well as our older-style <object> + <embed> codes.
If any of your existing code attempts to parse YouTube embed URLs that are entered by end-users, it’s important that you support both HTTP and HTTPS as the URL’s protocol across all the varieties of YouTube embed codes.

Most web browsers will warn users when they access web pages via HTTPS that contain embedded content loaded via HTTP. If your main site is currently accessed via HTTPS, using the new HTTPS URLs for your YouTube embeds will prevent your users from running into that warning. If your site can be accessed either via HTTP or HTTPS, you could employ protocol-relative URLs instead of hardcoding a value; //www.youtube.com/ will automatically resolve to HTTP or HTTPS depending on the protocol used by the host page.

It’s very important to note that this is just a first step in enabling HTTPS for the entire YouTube viewing experience. In particular, only the YouTube player code is accessible via HTTPS at this time. The actual video bitstream, and some additional content loaded by the YouTube player may still be accessed via standard HTTP connections when you use an HTTPS URL in your embed code. Also note that HTTPS remains optional for YouTube embeds; we have no plans to turn off support for the HTTP URLs.

If you have any comments or questions about this change, please let us know in the YouTube API developer’s forum.

Cheers,
–Jeff Posnick, YouTube API Team

YouTube Captions Uploader Web App

Thursday, January 27, 2011

Captions can greatly enhance the experience of viewing a YouTube video, and the YouTube API has offered developers ways to upload and retrieve caption data in authorized requests for a while now. However, the various YouTube API client libraries don’t natively support interacting with captions at this time, and writing your own code for uploading or retrieving captions can be challenging.

With that in mind, we're happy to announce the YouTube Captions Uploader open source project on Google Code, which provides real-world code for uploading captions to YouTube. The code is written for the Java App Engine environment, and it uses some nifty new App Engine features like the Channel API, the Blobstore Service, and Task Queues. And even if you're not an App Engine developer, we hope that the code that interacts with the YouTube API's captions service will provide a good starting point for writing your own code.

In addition to open sourcing the code for this project, we’re also running the code itself on a public App Engine instance, http://yt-captions-uploader.appspot.com/. So, even if you're not a developer, you can still use the application to upload captions for videos in your YouTube account.

Please share your comments or feedback via the project’s issue tracker. We hope that you find it useful both as a standalone web application and as a starting point for writing your own code!

Cheers,
—Jeff Posnick, YouTube API Team

Introducing JavaScript Player API for iframe embeds

Thursday, January 20, 2011

Update (July 2012): The onYouTubePlayerAPIReady callback has been superseded by onYouTubeIframeAPIReady and the URL for loading the IFrame Player API code has changed to http(s)://www.youtube.com/iframe_api. The API is now fully supported.
<iframe>announced<iframe>share videosan initial beta version of<iframe><!DOCTYPE HTML><html><body><div id="player"></div><script> //Load player api asynchronously. var tag = document.createElement('script'); tag.src = "https://www.youtube.com/iframe_api"; var firstScriptTag = document.getElementsByTagName('script')[0]; firstScriptTag.parentNode.insertBefore(tag, firstScriptTag); var done = false; var player; function onYouTubeIframeAPIReady() { player = new YT.Player('player', { height: '390', width: '640', videoId: 'JW5meKfy3fY', events: { 'onReady': onPlayerReady, 'onStateChange': onPlayerStateChange } }); } function onPlayerReady(evt) { evt.target.playVideo(); } function onPlayerStateChange(evt) { if (evt.data == YT.PlayerState.PLAYING && !done) { setTimeout(stopVideo, 6000); done = true; } } function stopVideo() { player.stopVideo(); }</script></body></html>YT.Playerhttp(s)://www.youtube.com/iframe_apidocumentationDeveloper Forum

A Chrome Extension for YouTube Activity Feeds

Wednesday, December 22, 2010

Slave Jovanovski, an engineer at YouTube, has put together a Google Chrome extension that should be of interest to the YouTube API community. It’s called YouTube Feed, and after installing and authenticating with your YouTube account, it automatically will fetch your YouTube social activity stream (both subscriptions and friends’ actions) while you use Google Chrome. When a new event, like a YouTube friend uploading or commenting on a video, takes place, the extension will notify you and provide details on the activity, as well as links to view the actual video. You have control over which types of activities you’d like to be notified about, as well as how frequently you’d like the extension to check for updates.

While you’ll hopefully find the extension useful on its own merits, the fact that the source code has been released as part of an open source project means that the extension’s code can serve as inspiration (or a jumping off point) for writing your own JavaScript code that interacts with the YouTube API. Curious as to how to use OAuth to authenticate YouTube accounts from a Chrome Extension? Or request JSON data with a JavaScript callback? The answers await you in the source code!

Cheers,
–Jeff Posnick, YouTube API Team

Engineering and Developers Blog