titaniumbunker.com

Evil geniuses and world domination are 2 of our goals... we also like Dr Who

So.. Google service accounts can’t access YouTube? oAuth-ful

no comment

Previously I have been working on using Jenkins to build a video file, and decided that I would need to investigate the ability to push the resulting video file from the build process to YouTube, allowing the continuous build process to make the results available for viewing.  A quick trip to the Google Developer Console  led to a page, detailing the YouTube Data API.  Looking at the opening paragraph – it certainly seems to offer the ability we’re after.

 

Add YouTube features to your application, including the ability to upload videos, create and manage playlists, and more.

 

So – let’s go through uploading a video by a script. A page discussing the upload video functionality  can be found here, and the code can be downloaded from Github.  My first thoughts were to implement this as a python script – after all it’s the same mechanism that we use to build the film in the first instance – so let’s give it a whirl.

Installing the Client Library

I’m developing on Ubuntu, so I’ve become accustomed to apt-get installing most of my applications, and I’ve written in the past about the benefits of something like software centre.  So I was a bit disappointed to see nothing in the instructions that there was no option to install the library from software centre – especially considering that Ubuntu is/was Google’s desktop of choice.  Anyway, the preferred option was to use Pip so I’d better install pip.

sudo apt-get python-pip

With that installed I was able to carry on looking at the python samples, but to do that I’d need to satisfy the other dependencies for the Client Library – primarily a google account, and setting up a project.  I already had a google account – in fact I had a couple of accounts, so the first part of those requirements were already fulfilled, and to be honest I don’t think that creating a google account requires a write up here but if you need to there’s a video here.

Creating a Google Account / Application

The sample code page says that the samples use the Google APIs Client Library for Python, so these samples needed that.  Creating a project or script that interacts with a Google API requires a developer to create a credential for that application within the Google Developers Console.  This means that google have the opportunity to see what application is sending the request to Google Services, and to provide a monetization capability.  Requests to the Google Services are limited, and large-scale users will end up burning through their daily allowance.  This allowance is not unsubstantial – the YouTube API allows 50,000,000 units/day and limit that to 3000 requests/second/users.  Not All requests are priced equally:

  • Simple read operation costs 1 unit
  • Write operation has a cost of approx 50 units
  • Video upload has a cost of approx 1600 units

these charges are approximate as the pricing is based on the number of ‘units’ returned – a search results could return a number of units per item.

Google suggest that the following operations would be achievable within the 50,000,000 units/day threshold.

  • 1,000,000 read operations that each return two resource parts.
  • 50,000 write operations and 450,000 additional read operations that each retrieve two resource parts.
  • 2000 video uploads, 7000 write operations, and 200,000 read operations that each retrieve three resource parts.

Google support a number of different types of authentication styles and there are 2 main types supported Public API and oAuth.  On the face of if the best option seems to be Public API as it allows a service to communicate with the server without user interaction, but Service accounts are not permitted to log into YouTube – so I’ll have to use an oAuth account.  The way that oAuth accounts work is as follows :

  • Application loads data from client_secrets.json – which allows the client application to identify itself against the google authentication services – Google now knows which application is being called.
  • User is presented with a browser -either directly by launching a URL, or through instructing the user through the command line to visit a particular site.
  • User then confirms that the application is allowed to access their youtube account
  • Google send back an authorisation token

This is all well and good for services that have a user front end – what I need is to do this in a system that runs on a back end, and then on a system that isn’t necessarily the system that runs the code (for example – through a client web browser).  There are difficulties related to storing and distributing these secrets based on the current scargo project.  Putting the clients_secret into the project would be  difficult, as any application would be able to masquerade as the Jenkins Video Upload application.  Storing the oAuth token would also be an issue, as anyone would theoretically be able to upload to my YouTube account.  Ideally I would have place holders into which your YouTube oAuth files could be copied – but that could prove problematic.  Pulling the latest code from GitHub would build, but wouldn’t deploy to the YouTube server without replacing these place holders with real data.  If the upload returned a fail status code, then the jobs would always fail.  If the placeholders were replaced from GitHub (and they might) then it would make setting up a new project more difficult.

What needs to happen is that the deployment needs to be separated from the build process.  This could be accomplished through creating a separate build job – a deployment job and running that on the basis of a successful build – however I made the decision that it might be better to create a Jenkins plugin.

You can find my current efforts here.

 

 

Tags:

Comments are closed.



Categories

Archives

Tags