I want to allow the visitors of my website to search videos of my youtube account by typing keywords. So far I've been using the "key" parameter to authenticate my other requests and it worked just fine, but for this specific one I am getting a 400 code when setting the myOwnparameter to true.
https://developers.google.com/youtube/v3/docs/search/list#request
If I understand what is said in the documentation by properly authenticated, I'd need to get into the hassle of setting up a OAuth flow just to do that. Beside the inconvenience, this doesn't even seem to address my use case since I don't want the user of my website to be authenticated with his account but with my account : I want the myOwn parameter to point to my account.
How can can I achieve what I am after, with a client-side only solution and - ideally - without OAuth ?
If you want the solution to be client-side only (e.g. a javascript front-end) your authentication credentials should be disclosed to every client and this could be dangerous because anyone could take control of your youtube account.
The solution seems to be to use the channelId parameter and set it to my account.
Related
I am creating an application which will be deployed on various sites and will upload videos from each site to YouTube periodically. I have already got videos uploading but ideally each site would have its own channel.
I had a search to see if anyone has encountered this issue (Don't reinvent the wheel, right?) but the only thing that I found was a couple of threads referencing the onBehalfOfContentOwner parameter detailed in the api here.
This isn't relevant to me as I'm not a content partner; at least I don't think I am. The Google API help documents then sent me here, so here I am.
I have created a YouTube brand account with, for the moment, two channels. Obviously, each one has their own channel id. So far I have tried the following:
Specifying the ChannelId when creating a Video Snippet, I couldn't see anywhere else to set it or an appropriate object to use. I tried with two different channel ids using the same OAuth credentials.
Creating two separate api projects with two unique OAuth credentials and then loading these credentials at runtime. I was only using one set of credentials throughout the lifetime of the app and then changed to the second credential set once I had tested that the upload was still working. The first credential set that I used prompted me to login and
subsequently select an account. The second set didn't prompt me at
all but the video was uploaded on the same account that I had
selected previously. I was logged out of YouTube and my browser was
closed in both instances; the browser does not store any details once it is closed.
I guess really my question is this. What is the best practice for specifying which channel you want to upload to? The application I'm using will be running automatically at set times, so I cannot have user interaction during the upload process. (Selecting an account during initial setup would be fine though!)
Any help is greatly appreciated. Thanks in advance.
EDIT:
I found that the API automatically uses an access token on the local machine if one is present in C:\Users{USERNAME}\AppData\Roaming\Google.Apis.Auth ; even if I am using a different OAuth credential in my application. Deleting the access token file will cause a login prompt to appear the next time you use the api from this machine.
For my application, this will be acceptable as when I deploy there is only the need for a one-time login and gain the access token which will then refresh every hour. It will also mean that I can choose which account/channel I am uploading to for each of our sites. Whilst I acknowledge the answer given by MαπμQμαπkγVπ.0, I do not believe that this is applicable here given that I am not a content partner as previously mentioned.
If someone can tell me how to do this through code instead of deleting the access token, that would of course be a preferred solution. (Or let me know that I am a content partner so I can try the onBehalf parameter)
I found that removing the OAuth token on the PC that my application is running on allows me to reselect the account/channel that I'm uploading to.
It appears that the authorised channel is determined using this token and once present it will automatically refresh every hour. Seeing as one PC will only ever upload to one channel for a given site, I think it is acceptable that I will have to go through a one time setup for each site to gain a token.
When you want to specify the channel you need to upload the video, i think you may need this parameter in your code:
onBehalfOfContentOwnerChannel- This parameter can only be used in a
properly authorized request. This parameter can only be used in a
properly authorized request. Note: This parameter is intended
exclusively for YouTube content partners.
The onBehalfOfContentOwnerChannel parameter specifies the YouTube
channel ID of the channel to which a video is being added. This
parameter is required when a request specifies a value for the
onBehalfOfContentOwner parameter, and it can only be used in conjunction with that parameter. In addition, the request must be
authorized using a CMS account that is linked to the content owner
that the onBehalfOfContentOwner parameter specifies. Finally, the
channel that the onBehalfOfContentOwnerChannel parameter value
specifies must be linked to the content owner that the
onBehalfOfContentOwner parameter specifies.
This parameter is intended for YouTube content partners that own and
manage many different YouTube channels. It allows content owners to
authenticate once and perform actions on behalf of the channel
specified in the parameter value, without having to provide
authentication credentials for each separate channel.
Our application can show rich links to webpages. So instead of a mere weblink we show a short summary and a picture. We used to use embed.ly's extract api to supply us with this data, but since they have changed their terms and pricing we have implemented an alternative solution.
The problem we find is that linkedin profile urls cannot be assessed by our new solution. Embedly was able to give us all the details we needed from a linkedin profile url (including the user's picture), but we don't seem to have access to that information without going through linkedin's API.
This call gives us all the data we are looking for:
GET https://api.linkedin.com/v1/people/url=[PROFILE_URL]:(id,email-address,first-name,last-name,headline,summary,formatted-name,picture-url,picture-urls::(original),site-standard-profile-request,public-profile-url)?format=json&oauth2_access_token=[TOKEN]
Where [PROFILE_URL] is a linked in profile url and [TOKEN] is the oauth2 access token.
There are two issues that I have:
Our application does not ask users to authenticate through linkedin, so we do not have a user oauth2 access token available;
Linkedin's suggestion in their FAQ (https://developer.linkedin.com/support/faq) seems very daft:
Can I get an access token for my application that doesn't require a member to login?
We do not provide access tokens for applications that are not associated with a particular LinkedIn member.
If your application requires you to make API calls in an automated way - without user interaction, you need to bootstrap the first access token request by manually signing in, and then ensure that your application refreshes the token automatically prior to expiry to avoid the need for additional human authentication.
Now... four questions:
a. Has anyone implemented option [2] in a production setting?
b. If yes, what are the limitations, downsides etc. Is this really the best and safest solution?
c. Is there any alternative that allows me to authenticate the application itself with its mighty client key and client secret?
d. Is there anyone from linkedin monitoring this? If yes, can you contact me?
Cheers, Raymond
I would like to give the posibility to my website users of entering their email, name, etc. only one time, and make it possible to register with those credentials to Youtube or Flickr direcctly. Is it possible to do it with some of their apis?
Thanks to all!
You cannot register a user to Flickr. Only flickr can do that. In fact, in the API you're not even handling the password. It's all done on flickr's turf.
I guess Youtube is the same (it would make sense since Google also uses Oauth).
I have a corporate website that I want to pull in tweets to, but i'm getting a rate limit using the http feed. So, I want to use an authenticated method to get the tweets.
Do I really have to register an application to do this, even though it's not really an application and my users will never be entering or changing the twitter account info.
Also, my corporate site doesn't have a public address, and registering an application through twitter appears to require a public url. So how can I get around this? Do I have to create a "fake" application with a public url, just to generate my keys?
Thanks for any help on this.
If your site is behind a proxy server along with all your users, using Javascript/jQuery won't help. All the requests will still be coming from the same IP and will hit a rate limit, as you're doing now.
The other issue is that you don't need to register an app to request a feed. Apps are only needed for Oauth, and getting a feed doesn't need that.
The best way to deal with this is to get the feed with a server script, store it on the server, and then deliver the server copy to the web pages. If you request the feed less than 150 times per hour, you won't have a limit problem.
If you want more than a single feed, you can use the streaming API to get all the tweets for up to 400 keywords or from up to 5,000 users. This still doesn't need a registered app, since the streaming API still allows Basic Auth.
Just wanted to post this for future reference and in case anyone else has the same question. The solution to my problem, was to register an application on twitter. But since I'm just using a single user, you don't have to do the regular OAuth steps of generating a request for a key, getting the response etc. Every app you register in twitter get's its own "Access Token" that you can use to retrieve tweets etc. So, this is what I ended up doing to solve the problem I was having.
Additional details: My main concern was having to do the OAuth steps of requesting an access code etc... Since my application is only a single user implementaion (just pulling in our company related tweets from company held twitter accounts), it just seemed unneccesary to have to do all of that. But what I found was that when you register an app on twitter, you get a private access token for each app. You can view a little information about that here: https://dev.twitter.com/pages/oauth_single_token.
It sounds like you are pulling the feed down over http on the server? You could just limit the updates so you don't hit the rate limit.
I would recommend instead doing this on the client side. There are a lot of very easy to use embeddable java script twitter clients out there. The rate limiting problem would dissapear as the feed would be coming from the desktop and not the server (unless they just kept refreshing it).
The Twitter developer wiki lists a few.
JQuery plugin for Twitter
Tweet (another JQuery plugin)
I asked various questions about my problem (here and here) and I also asked in the #oauth & #openid freenode's channel on IRC. (this is note an "UP" question, it's an other problem)
I'll sum up my project configuration : Anyone will have the possibility to create an app that can use my API. To start, I'll work on my API and a Web based app, but the documentation about the API will be public. It's a bit like Twitter API.
The problem I face is how can I be sure which user is using the API (to retrieve his personal data, like your tweets), even if the User is using an app that I don't know who make it (again, like twitter and all the apps around).
I googled a lot and with the help of the previous answers given, I took a look at OAuth.
As far as I understood the way OAuth works, here how :
A user visit an app that use my API (web, mobile, whatever)
The apps redirect the user to the API for the authentication (I'll use OpenId) and the authorization (OAuth). This is a bit odd since the API will have a web interface for the login and the authorization (I suppose this is how it works since Twitter do that)
The API redirect the connected user to the app, with some tokens. In these tokens, there is a token representing the user that the app must store in order to indicate to the API which user is using it currently (Am I correct?)
So far, everything goes well. But what I can't figure it out, is when the user quit the app and goes again : how the app can remember the user is the one that used it before ?
(Before some of you bring me the cookie answer, I'll remark this is a simple example, it would be the same if the user clear his cookies, format his computer or change its computer.)
The only solution I can find, is when an unauthenticated user (without a remembering cookie for example) goes to the app, the app redirect him again to the API to authenticate himself, but this time, the user won't have to re-allow the app (authorization) since it already did it. The API will then return the user to the app to allow him to play with this.
Is this the proper & secure way to do it ?
The #OAuth IRC channel told me about the new protocol, WebID, but this is currently in pre-draft mode and I don't want to use something that will change continuously in the future :/
Thank you very much for your help!
Short answer: OAuth results in an authenticated access token. That access token is tied to ONE user. And as long as the access token is valid. The third application can do whatever the API allows the access token to do.
Long answer:
The thing with OAuth is that it does not "Log in" a user. OAuth gives third party applications what is called access tokens which can be used to access data on behalf of a user whether he/she is logged in or not.
Many services restrict their access tokens. Twitter for example issues two types of access tokens, read-only, and read/write. But there is no concept of logging in to use APIs. While an access token is valid, a third party application can access the user's data, and change things without a user's explicit interaction.
Most API providers have functionality to revoke access tokens. That is what happens when you in twitter look at your Connections page . See the revoke access links?
Personally I love the OAuth approach. As an API provider, you can control what access tokens are allowed to do, and the user can kill bad applications from using his/her resources. OAuth is secure as far as authentication goes. Third party applications do not get hold of user's passwords. But once authenticated they can do whatever your API allows.
if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:
The thing is, when you want to allow any 3rd party application to use Twitter, this application redirect you to the OAuth page of the Twitter API, IF you are connected, but if you aren't, it redirect you to the login page, which is located at http://api.twitter.com/login
(I don't know if keeping the api in api.twitter.com for loging an user, instead of just twitter.com is correct, but this is just semantics)
So, the workflow would be:
A user goes to a 3rd party application (like a website)
This third party redirect the user to the API for Authorization
The API redirect the User to the website for Authentication first
The official website redirect the User to the OpenId provider (or Facebook connect)
The Authentication is made (via multiple requests)
The website redirect the user to the API after he's successfully authenticated
The user allow/disallow the permissions asked by the 3rd party apps
The API returns to the 3rd party apps.
The User can now use (or not) the application.
This implementation have 2 problems:
Every time an User ins't authenticated (cleared it's cookies, connect himself from an other computer, etc), he will have to go through the Authentication method, by being redirected to the Official website and then being redirected to the 3rd party application (the API would be transparent, since it has already allowed the application to access his data).
All those layers would certainly lost the User on the Authentication process with too many redirections.
A possible solution would be to store the user's access_token, for example in the case of a mobile app, but with a pure html/css/js oriented app, this isn't possible. A login/password in the 3rd party web application that would match the user to the access_token of the API would be an other solution, like Seesmic (I think), but this is just useless (for us, not Seesmic) : the idea of not having the user's password become useless.
This is a possible explanation but I would require more details on how this is possible and your thought about that solution. Would it work?
(I added this as an answer since it's an (incomplete and not so sure, I agree) one.