YouTube API

Hi, has anyone integrated with the YouTube API?

Specifically I am looking for the best way to upload local Desktop videos to YouTube from within my Xojo Desktop App. One option would be to use Shell and write it in another language, but I think it would be better if it was in Xojo itself.

Any thoughts on the best place to start would be very welcome!

[quote=116887:@Chris Copleston]Hi, has anyone integrated with the YouTube API?

Specifically I am looking for the best way to upload local Desktop videos to YouTube from within my Xojo Desktop App. One option would be to use Shell and write it in another language, but I think it would be better if it was in Xojo itself.

Any thoughts on the best place to start would be very welcome![/quote]

Hey Chris,
Have you figured this out yet?
I am currently trying to get the whole oAuth thing to work in order to log in from a desktop app. The redirect uri is still kind of confusing to me. Other than that things seem pretty straightforward.

For redirect uri.
If you have a vps or any website you can make a simple html page as callback.
Something like this.
http://MySite/callback.html
Then catch the header for the token or the key.

This from paw and a test i have make to get the token in spotify,but is the same for youtube.

[code]// Get authorize

// Set up the socket
// “mySocket” should be a property stored elsewhere so it will not go out of scope
mySocket = new Xojo.Net.HTTPSocket
mySocket.RequestHeader(“Cookie”) = “csrf_token=AQD-L78zfe-F7I5bME0OiO0iQ1yxx5Y4RDZZZ3unafRSBhNhFSP_jOu7UuC4oPhKAo44g2nbzR0G”

// Set the URL
dim url as Text = “https://accounts.spotify.com/authorize?client_id=myID&response_type=token&state=ef617a41-f9d5-4591-9a89-51b0a5ef2f8e&redirect_uri=http%3A%2F%2Fdecobu.eu%2Fcallback.html

// Send Synchronous Request
mySocket.Send(“GET”,url)[/code]

Awesome!
Do I have to catch the headers on the VPS?
I thought I got the responses back in the HTTPsocket events

I’m working on this at the moment.

There are a couple of ways to do this:

  1. Let the user auth through their own browser
  2. Utilise a HTMLViewer in your app.

If you go route 1:

Have the redirect_uri set to one of three methods

redirect_uri http://localhost:port, urn:ietf:wg:oauth:2.0:oob

  1. A local port where your app simulates a web server and presents a page saying thank you, all done etc. Your app can then reads in the data that is passed to your web server (in your app) from the API. Possible implications with this are firewall settings. I’ve not tested this fully yet with a locked down (default install) of windows. You can always set the port in the 10000 range which windows firewall should ignore as I only think it gets worried about low numbered ports impersonating something important, again, not tested this yet.

urn:ietf:wg:oauth:2.0:oob
2) Shows the user some codes to paste into your app. Needs user interaction, but simple to do.

redirect_uri urn:ietf:wg:oauth:2.0:oob:auto
3) Sniff the title off the browser. Get a handle to the browser window and read its title. You can have the api return to a basic page that updates the title of the page.

If you go route 2:

This is a lot easier as you have full access to the web browser in your app so you can use redirect_uri urn:ietf:wg:oauth:2.0:oob:auto and auto-skip to another page or screen in your app when you’ve detected this stage.

However the down side of this is that the user won’t always “trust” your app with their login details and they might not have simple access to a password manager that might work with their favourite browser but not for your embedded browser.

Trust in your app is neither here nor there as you could always be sniffing the key presses system wide, users don’t really think about this thought. Giving them the option of the two systems might be best. I’ve not got this far yet though, so I’ll find out when I come to it.

Plenty of info here in case you’ve not found that page yet https://developers.google.com/identity/protocols/OAuth2InstalledApp

Hope this helps.

[quote=264098:@]I’m working on this at the moment.

There are a couple of ways to do this:

  1. Let the user auth through their own browser
  2. Utilise a HTMLViewer in your app.

If you go route 1:

Have the redirect_uri set to one of three methods

redirect_uri http://localhost:port, urn:ietf:wg:oauth:2.0:oob

  1. A local port where your app simulates a web server and presents a page saying thank you, all done etc. Your app can then reads in the data that is passed to your web server (in your app) from the API. Possible implications with this are firewall settings. I’ve not tested this fully yet with a locked down (default install) of windows. You can always set the port in the 10000 range which windows firewall should ignore as I only think it gets worried about low numbered ports impersonating something important, again, not tested this yet.

urn:ietf:wg:oauth:2.0:oob
2) Shows the user some codes to paste into your app. Needs user interaction, but simple to do.

redirect_uri urn:ietf:wg:oauth:2.0:oob:auto
3) Sniff the title off the browser. Get a handle to the browser window and read its title. You can have the api return to a basic page that updates the title of the page.

If you go route 2:

This is a lot easier as you have full access to the web browser in your app so you can use redirect_uri urn:ietf:wg:oauth:2.0:oob:auto and auto-skip to another page or screen in your app when you’ve detected this stage.

However the down side of this is that the user won’t always “trust” your app with their login details and they might not have simple access to a password manager that might work with their favourite browser but not for your embedded browser.

Trust in your app is neither here nor there as you could always be sniffing the key presses system wide, users don’t really think about this thought. Giving them the option of the two systems might be best. I’ve not got this far yet though, so I’ll find out when I come to it.

Plenty of info here in case you’ve not found that page yet https://developers.google.com/identity/protocols/OAuth2InstalledApp

Hope this helps.[/quote]

I have seen apps where a user enters the right username and password. The app itself takes care of uploading. Does that require the same approach as you described here? I can’t find the right documentation where I can send in the user’s credentials in order to obtain the right tokens.

You [quote=264410:@Edwin van den Akker]I have seen apps where a user enters the right username and password. The app itself takes care of uploading. Does that require the same approach as you described here? I can’t find the right documentation where I can send in the user’s credentials in order to obtain the right tokens.[/quote]

This is from the API

oAuth was mainly developed for sandboxed environments like web servers, iOS and Andriod where you dont want the app login to have access to a users account and the user doesnt want to enter their precious login information into your website or app. Its a bit different for a desktop app as you could be doing nefarious stuff without the users knowledge anyway, like listening to keystrokes when they are typing their login details into chrome in a separate window so its a bit less of a trust issue on desktop anyway.

If you captured the users youtube login details, you could add a developer API key to their account and use that and that would probably be fine for a custom app that only a few people will use.

I would stick with the oAuth and keep it separate from your app. If you dont and if someone’s account gets compromised shortly after using your app, they will be looking at you first because you just took all their details into your app.

I personally would stick with oAuth, it’s not that tricky once you get your head around the log in process.

Api key should only be used for application based use e.g. Upload to your company yt profile.

Use Oauth to authenticate a user and act on his behalve.

You may get a token for Oauth by using HTMLViewer and ask for the right url. Let the user login and catch the token somehow.

That should help you in the right direction.

@, @Derk Jochems Thanks!
I will look into the oAuth as soon as I can. I thought of using the HTML viewer. Seems like the only way to go for me, at this moment.

My Tip.
If you want to use google api’s then get the Paw .
The Google api(Youtube) is a bit complicated with oath callbacks because of the scopes and access types.
The second problem with youtube will be the refresh tokens if you want a list of youtube videos.
?he third problem will be the access_type= ? offline,online that mean if is offline then your app need to refresh tokens in time.
You find more informations for this in youtube api.
To me was more easy to make a simple empty .html page and redirect the callback there,from there i get anything i want.
Because of api use Post-Get for me was easy with paw.

Yeah, I got Paw a while ago, when @Paul Lefebvre mentioned it in his webinar. Looks like it is still quite complicated though. But, I will check out in what way Paw will help me.

That is what I am trying at this moment. Thanks Derk :slight_smile:

Did anyone get a working example to login into that youtube.data.api ? This seems extrem complicated cause we dont have any dlls from google like in .NET

Just catching up with this thread, there’s a couple of points I want to add for the Mac.

#1 The browser trick won’t work in the App Store as App Sandbox prevents your application from accessing Safari cookies. You can still use an HTML viewer within your application, but it will require the user to re-login to YouTube from within your application.

#2 NSSharingServices has/had a built-in YouTube function.

Sorry it doesn’t, it supports Vimeo and two Chinese services. I was pretty certain I’d seen YouTube, maybe Apple removed it.

[Update] Turns out Apple never implemented it system wide, only for their apps.

I wrote some oAuth code many years ago, we don’t use it anymore, but you’re welcome to use it or examine it and see if it helps.

http://www.ohanaware.com/xojo/photoSharingWithoAuthAndCURL.zip

[quote=265236:@Sam Rowlands]I wrote some oAuth code many years ago, we don’t use it anymore, but you’re welcome to use it or examine it and see if it helps.

http://www.ohanaware.com/xojo/photoSharingWithoAuthAndCURL.zip[/quote]

Wow! Nice work! I am digging through your code now. I think this will point us all into the right direction.

[quote=264804:@Loannis Kolliageorgas]Simple example with htmlview.
File[/quote]

I like this one. It was posted in another conversation. It handles the login process for YT very well. Yet, no refresh tokens were used. But that will be fairly simple to implement, I think.

The access code can be found in the Title of the HTML document. After a successful login it starts with "Success ". The Code can be found after code=

Oh, don’t forget to insert your client_ID in the initial url :slight_smile:

https://itunes.apple.com/us/app/cookie/id415585910?mt=12

And for OS X 10.11+: https://itunes.apple.com/us/app/cookie-5-more-privacy-better/id1048338802?mt=12