YouTube API broken by Google. 'Authentication with Google failed. Reason: NoLinkedYouTubeAccount' - youtube-api

** UPDATE **
It truly seems that Google has just screwed every single person on the planet by absolutely requiring user interaction to upload a video. Of course I know, they are free. Exactly what I warned the client years ago about, so I don't need to be reminded. Thank You.
So I would like to try to take this in a different direction and just find a loophole and a workaround to still keep doing what we are doing in spite of Google's complete lack of support or caring in any way about the developers and what they have to deal with.
It would be different if you can actually call a phone number and talk to a human being about YouTube Partner access, but you can more quickly get access to the Illuminati.
OAuth 2.0 is now the only supported authentication method period. It does require user interaction.
But what about that token? Does anybody know how long the token lasts?
If I can obtain a token just once using user interaction and place it in the database, I can automate possibly hundreds or thousands of interactions afterwards.
In other words, I'm trying to turn the user interaction into a speed bump instead of a concrete wall.
If anybody has any examples of obtaining that token, caching it, and using it afterwards, that would be a godsend to me right now.
Thanks for the comments and the help. I'm not surprised that the YouTube Developers Forum just folded and said to come here instead :)
It seems that Google has completely pulled the plug on the existing dashboard.
https://code.google.com/apis/youtube/dashboard/gwt/index.html
That link is now 404'd. Tried from several different browsers on different systems.
Registered under the new Google APIs Console already, but still get the problem.
// Set the authentication URL for this connection object
$authenticationURL= 'https://www.google.com/youtube/accounts/ClientLogin';
// Try to connect to YouTube with the channel credentials passed
try {
$httpClient =
Zend_Gdata_ClientLogin::getHttpClient(
$username = $channelfields['EMAIL_ADDRESS'],
$password = $channelfields['PASSCODE'],
$service = 'youtube',
$client = null,
$source = 'Redacted Data',
$loginToken = $channelfields['CACHED_TOKEN'],
$loginCaptcha = '',
$authenticationURL);
} catch (Zend_Gdata_App_HttpException $httpException) {
$update_error['response_body'] = $httpException->getRawResponseBody();
$update_error['error'] = 1;
} catch (Zend_Gdata_App_Exception $e) {
$update_error['message'] = $e->getMessage();
$update_error['error'] = 1;
}
This code has worked perfectly fine before, but does not work with the older API key, or the newer one generated inside the Google APIs console.
I'm attempting a simple upload and this concerns me greatly:
"The service account flow supports server-to-server interactions that do not access user information. However, the YouTube Data API does not support this flow. Since there is no way to link a Service Account to a YouTube account, attempts to authorize requests with this flow will generate a NoLinkedYouTubeAccount error."
From all reports it seems that Google has forced YouTube uploads to become interactive in all cases precluding all possibility of platforms that automatically upload generated content from working at all.
Any help or insights into the process is appreciated.
P.S - Ohhh, it's been awhile since I looked at that system and Google shut down the YouTube Developer Forums and said "YOU" were responsible for their support now :)

OAuth2 does support the ability to avoid user interaction through the offline access type parameter (ie, using access_type=offline). Check out Google documentation for details.

The solution is really rather simple. Your app needs to use oauth to request offline access. It will be given an access cide which you convert to a refresh token, which is the thing you store in your database. This doesn't expire. Well actually it sometimes does, but that's another story. Whenever you need to access the api, use the stored refresh token to request an access token which you include in each api call.
See https://developers.google.com/accounts/docs/OAuth2WebServer for details.

I don't know what you did but https://code.google.com/apis/youtube/dashboard/gwt/index.html works perfectly fine for me. Maybe it was a temporary issue. If you want no user interaction you HAVE to use YouTube API v2 OR you have to use v3 with methods that don't require authentification OR you have to provide your own youtube account credentials which is not recommended and probably not appropriate for you situation.

Several issues to respond here, I think.
1) The older API console has not been removed, but I've noticed intermittent outages to it and to the newer API console while Google is rolling out their new "cloud console."
2) ClientLogin was officially deprecated in April of 2012, not just 48 hours ago. Jeff Posnick has detailed all the changes over the months (and related ones, such as AuthSub, Youtube Direct, etc.) at his blog (apiblog.youtube.com).
3) You're right that, with v3 of the APIs, you cannot do automatic uploads across the board, as the oAuth2 flow requires user interaction. However, given the limited description of your use case, using refresh tokens is probably your best bet. If the content is user generated, somewhere they must be logging into your app, correct? (so that your app knows which credentials to leverage to do the uploads). At the point they're logging into your app, and you're starting the oAuth2 flow, you just have to hit the first oAuth endpoint and pass it the parameter access_type=offline (along with any other parameters). This will ensure that, when they grant that initial permission, you're returned a refresh token instead of an access token. With that refresh token, you can exchange it for multiple access tokens as needed (an access token lives for about an hour. I don't know how long a refresh token lives, but I've never had one expire before my own login cookies did, and then I just get a new one when my users re-login to my app).
Here's some more info on how to use the refresh token; note, too, that the various google api client libraries make it pretty smooth.
https://developers.google.com/accounts/docs/OAuth2WebServer#refresh
Also, this video tutorial from a Google Developers Live broadcast a couple of months ago might help illustrate the point: http://www.youtube.com/watch?v=hfWe1gPCnzc -- it's using the oAuth playground rather than a client library, but the concept is the same.

The answer is to use google-api-php-client, create an interactive auth page, and set up YouTube API v3 correctly with the new API console.
You can create a very simple page that will authenticate for the supplied channel and then store the correct token in your database. Is already working and uploading hundreds of videos on one channel. You do need to remember to fully activate yourself under the new API console and add the services required. Just keep authenticating and adding the services it says it needs. After that, the regular v3 upload process works just fine. On failure send a group an email and they can get a new token in 10 seconds.
Not the most elegant solution, but the documentation from Google is far from elegant anyways that Stack Overflow is now their front line support.
Just hang in there, a solution is always found. Don't give up!
I didn't get here by myself either, the other answers on this page helped me get all the way to this point. Thanks guys.
P.S - Don't forget the scopes
$client->setScopes("https://www.googleapis.com/auth/youtube https://www.googleapis.com/auth/youtube.upload");

Related

Is it not possible anymore to use chat:write:bot scope for Slack apps

I want my app to chat.postMessages to Slack, using the icon_emoji and username parameters so that I sometimes change the icon and name displayed.
From the doc of the method, it seems I have to set as_user to false. But when I do so, I'm getting a missing_scope error: I need scope chat:write:bot. (Same error whether I use my OAuth access token or my OAuth bot user access token)
But from this page I got that they are disappearing? So are the parameters I want to use (icon_emoji and username) going to disappear as well?
No, as of Dec 19 2019, you cannot use icon_emoji, etc
I ran into the same issue, and so I opened a support ticket with Slack. After a few messages back and forth, I got confirmation that this is likely a bug:
With your help I was able to replicate the issue. I suspect this is a bug but I've escalated it to the Granular Bot Token team for a second opinion. As soon as I have more details I will let you know.
Edit:
I've received another update, which I've trimmed down to the essentials:
When building the Granular Bot Token model our team really wanted to use this as an opportunity to slowly deprecate certain API behaviour. The as_user parameter is one of them. See the following comment from (https://api.slack.com/authentication/quickstart).
One effect worth noting: chat.postMessage and other chat.* methods no longer mess around with the as_user parameter. You're granted a single chat:write scope (no :user or :bot is appended). If you call the chat.postMessage method with your bot token, you post as the bot. If you've obtained a user token through the new install flow, and you call the method with your user token, you post as the user.
So in regards to the action you are wanting to take, I'm afraid it's not possible with Granular Bot Token. We also recognized that the error this is throwing is completely unhelpful and confusing for developers. For this, we've created a bug to fix the error that's returned when Granular Bot tokens try to make restricted API calls.
I've requested clarification on whether it is just the as_user part that is deprecated, or the icon_emoji part as well.
Edit 2 (Dec 19, 2019 13:38 EST):
One, probably final, update:
The option for app to change information such as username, avatar and icon via the API is up for debate as well. Currently with Granular Bot Tokens you can only update that information via your API management page.
Which is really unfortunate.
I had to add a Scope to "Bot Token Scopes" with the value of "chat:write.customize".
https://api.slack.com/scopes/chat:write.customize
then I had to re-install my app. And it worked like I expected.
Note: I tried this as it was a suggestion from a comment. but it worked so i am adding it as an answer.

Google OAuth is making call to Youtube API

I am trying to use Google OAuth2.0 for authentication. Everything is working fine but on initial(first) loading it is taking extra time (30 seconds-RequestTimeOut) on client side(Web-App) to load prompt. I've checked the Network Tab (Developer Console-Chrome), where I've found that it is trying to make call to
https://accounts.youtube.com/accounts/CheckConnection?pmpo=VALUE&v=VALUE&timestamp=VALUE.
This request is failing with ERR_TIMED_OUT, and In my organization we don't have access to Youtube (That I'm aware of it). But Why and Where my application is making request to Youtube API is my question. If so How do I stop this (fetch accounts from youtube)?
The scope of My App goes like this
"scope": "https://www.googleapis.com/auth/drive https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/userinfo.profile"
It is happening on initial load itself, later it is giving 200 status for the same request. What am I missing.
I'm completely new to this. (Sorry, If it is noob question)
Thanks in advance.
Edit::
I came to know why it is making request to youtube api, It is trying to fetch any other accounts(login users) from youtube(gmail-accounts). But how to stop making request to youtube(accounts.youtube.com). It is fine for my application to fetch accounts from google(accounts.google.com).
Thanks.
Google puts an iframe inside google o-auth account picker.
Google oauth and youtube accounts iframe
Analyzing the javascript inside that iframe, we find some evidence that, this might be an approach to load youtube session, in order to get the userId for the current logged user in Youtube.
By creating an iframe, you get the normal context of opening an website, this is, you get access to session information.
And it's exactly what this is used for, proof:
//# sourceURL=/_/mss/boq-identity/_/js/k=boq-identity.AccountsDomaincookiesCheckconnectionJs.pt_PT.4FJ4-a_ocZ8.es5.O/d=1/ct=zgms/rs=AOaEmlHUdMtrscDWG6wHCiHHFunuI9afAg/m=base
if (window.parent && window.parent.postMessage) {window.parent.postMessage( google.checkconnection.getMsgToSend('youtube', 'some_id'), 'https:\/\/accounts.google.com');}</script>
iframes can communicate, as long as one another is listening to this messages.

LinkedIn, 401, Unable to verify access token

I used this guide to built a showcase - sign in with LinkedIn into a specific site.
Everything worked perfectly until I demonstarted it in front of a wide audience and it broke down :-( It was a great FAIL and I want to know why. Here is what I do:
1.On the sign in page the user may click a Sign in with LinkedIn button and is redirected to similar link:
https://www.linkedin.com/oauth/v2/authorization?redirect_uri=[my_callback]&client_id=[my_client_id]&response_type=code&state=[securely_random]&scope=r_basicprofile%20r_emailaddress
2.The user allows the application and is sent back to my_callback
3.In my_callback I make a POST to https://www.linkedin.com/oauth/v2/accessToken in order to obtain an access token. I use the code sent by LinkedIn, correct client ID and secret. Everything is OK, e.g the response might be:
{
"access_token": [access_token],
"expires_in": 5184000
}
4.I make authenticated requests to fetch the profile data from endpoint https://www.linkedin.com/v1/people/~:(firstName,lastName,email_address)
Headers:
x-li-format: json
Authorization: Bearer [access_token]
I started to get an error 401 occasionally, e.g.:
{
"errorCode": 0,
"message": "Unable to verify access token",
"requestId": "YX21AN6NZG",
"status": 401,
"timestamp": 1483732371224
}
It seems that some of the requests randomly passed nevertheless...
Additional details:
The user is logged in LinkedIn
The user is administrator for the LinkedIn application
I have checked the limitations (throttle limits) at in the application. Available at https://www.linkedin.com/developer/apps. Everything which can be seen is green.
I have tried all advices and hacks from this question
My app is not live
I'm puzzled!
Question: Any obvious mistake?
Question: Is there any hidden throttle limits (or security instruments) for the limitation of the number of access tokens for specific user/app combination? (I'm always using the same user and I tested pretty aggressively before the big FAIL)
UPDATE: In the next two days the Sign in started working smoothly again as described above. No 401-s anymore... :-X I've made no changes to the code base. So is this some kind of throttle limit or just LI was in a bad mood on Friday?
In case someone is curious I got an answer to my problem from LI support:
Unfortunately, we really can't assist with API issues and 3rd party apps. My guess is that there was a hiccup on Friday and you were the victim of bad timing.
I accept the explanation that I was a victim so this answers my question...
I have an access-token that worked to get data through the API, however now it has stopped working. I've carefully read LinkedIn's documentation: https://developer.linkedin.com/docs/oauth2 and have come up with why this can happen.
The docs state, that the user's session is linked with the access-token. Therefore, logging out of the session means the access-token is invalidated. This makes sense because it's exactly what I see happening.
The oauth2 expired-at is just a timestamp of the ultimate time this access-token will be valid. But it can be invalidated at any moment apparently.
Other oauth2 implementations show features for refreshing the access-token, Linkedin does not provide such feature. Therefore a user has to refresh it manually every time. Not sure if this is by design or they haven't got around to it yet. Overall their API feels pretty out-dated.

Automatic login

I am looking for a way to load simperium without having to present the login view after the first time the user enters his info.
This is what I get if I dont log in after the first time:
Simperium error: bucket list not loaded. Ensure Simperium is started
before any objects are fetched.
This is what I use to init Simperium:
self.simperium = [[Simperium alloc] initWithRootViewController:
_window.rootViewController];
thanks
Consider using OAuth.
OAuth is a system where the user can provide their credentials for a popular service like Google, Twitter, Facebook or other open ID providers.
Rather than caching the credentials on the device, which would be insecure, since getting access to these would give the user access to a large number of systems, OAuth gets the main authentication service to provide a token.
This token gets stored on the device and can be used to login automatically the next time.
The drawback is that it can be quite tricky to set up the first time, since there's quite a lot of complexity going on, not to mention that the standard is quite new so there was some evolution in the specification.
Simperium just needs user credentials to get started (the app id and username/token). The login view is a convenience to get those credentials for you, if you can already obtain them using some other means (like using HTTP auth API: https://simperium.com/docs/reference/http/#auth) then you can directly supply those without using the login view. See methods in https://github.com/Simperium/simperium-ios/blob/develop/Simperium/SPAuthenticator.m

"Remember this approval" when using dotNetOpenAuth and Google Apps doesn't work as expected

I'm using dotNetOpenAuth to provide SSO to my app via a user's Google Apps account. Besides just simple authentication I also ask Google to return the user's email, first name and last name. When a user first goes in they get redirected to the typical Google Accounts page telling them that the app is asking for this info and do they want to allow it. There is the checkbox there to Remember This Approval. The problem is, the approval isn't being remembered. It does remember them if they go back to the site without closing their browser. But if they close their browser and then open it later and go back in, they are again prompted to allow it.
If I look through my Google account page that shows me connected sites, apps, and services, I see my app listed multiple times. It's like it doesn't recognize that it's the same app and keeps adding it.
I know I must be missing something obvious, but I'm not sure what it is. Any ideas?
Thanks!
You can find my code here
I see several problems in your code. To first answer your direct question, the reason Google doesn't remember you on return visits is because you are passing a random GUID in as part of your Realm each time you log in. The symptom is actually much worse than you realize. It's not just that Google prompts the user on return visits, your site won't recognize the user at all on return visits because Google will give them a new claimed identifier on each visit.
The fix is that you should use the exact same Realm for every login request:
Realm realm = "http://www.yoursite.com/";
var req = openid.CreateRequest(discoveryUri, realm, URIbuilder.Uri );
Or my personal favorite:
var req = openid.CreateRequest(discoveryUri, Realm.AutoDetect, URIbuilder.Uri );
Realm.AutoDetect will work for you unless your site is available both via HTTP and HTTPS, in which case you need to lock it down to just one or the other of these so that Google recognizes your site as always the same.
You must also remember that the returnTo URL that you pass in as the 3rd parameter to CreateRequest must always be based on the realm. So if your realm is HTTPS, so must your returnTo parameter be.
I also want to call out that you seem to have some GUID code and complex URL manipulation around trying to ensure that every OpenID response you accept comes from a request you sent out. I'm not sure why you're trying to do this in the first place, although there certainly can be legitimate reasons. The way you did it is insecure and can be circumvented. I suggest you delete all this code, in favor of adding this to your web.config file:
<dotNetOpenAuth>
<openid>
<relyingParty>
<security rejectUnsolicitedAssertions="true" />
</relyingParty>
</openid>
</dotNetOpenAuth>
The library has support for requiring all responses to come from your requests built in, and it does so securely so that the security exploit I alluded to earlier isn't possible.
But if you're only trying to apply this restriction so that you know it's coming from Google, may I recommend that instead of rejecting unsolicited assertions, you instead check the IAuthenticationResponse.Provider.Uri property when you receive responses and verify that it is coming from the Google OP Endpoint? Then, if Google ever supported sending unsolicited assertions it would work on your site, and ultimately your security gate is exactly where you intended it to be anyway.

Resources