YouTube API and brand account - google-apps-script

I am using, since a long time, a Google script that accesses my YouTube channel, gets and modifies some information from it and saves some data in a Google sheet.
It always worked fine, but then, about a week ago, Google somehow split my access rights between my normal account (primary email) and my YouTube account (that goes under a different nickname).
I cannot find a way to run even the simplest command:
var my_playlists = YouTube.Playlists.list('snippet', {
mine: true,
maxResults: 50,
})
.items;
The problem is that google now prompts me with an authorization page and I can choose between 2 accounts. One is my primary account, the other is the YouTube one.
If I choose my primary account, the code runs but I cannot see the data of the YouTube account.
If I choose the YouTube one, I still cannot access the data I want and it keeps asking for permission every time I run the code.
I understand there is a problem of authorization between the two channels, but I did not have it before and cannot find any suggestion to solve it.
What can I resolve this problem?

I've been struggling with the exact same issue but for another cause.
Anyways, so far I can manipulate anything I want within my PERSONAL youtube account, granting access using OAuth to MY ACCOUNT, but if grant access to my branded account, the script doesn't even begin, apparently it's a bug that causes loop in the script.
You can check this out for more info:
YouTube Apps Script API only runnable by accounts without a YouTube channel?
https://issuetracker.google.com/issues/36764531
https://mashe.hawksey.info/2017/09/identity-crisis-using-the-youtube-api-with-google-apps-script-and-scheduling-live-broadcasts-from-google-sheets/
Using Youtube Data API to Edit with Brand Account Playlist

Related

Google App Scripts (Sheets) not connecting YouTube brand account

The problem:
I've been stuck trying to figure this out all day. I'm writing an app script within my Google Sheets to query YouTube API data from a particular YouTube channel, and it works when I connect every account but the actual YouTube account (brand account) we're trying to query.
The setup:
youtube.email#gmail.com - where the YouTube account is hosted.
ryan#gSuiteCo.com - where I am writing the script.
What happens:
When I execute my code, it asks for authorization, so I log in with youtube.email#gmail.com. Then it gives me the option to choose the YouTube Brand account or the youtube.email#gmail.com Google account. If I select the email Google account it works (but then is pulling from the wrong YT account). If I select my YouTube account, nothing works, and I end up in an authorization loop. I hit run, and a pop-up asks me to authorize. After authorized, it doesn't actually run... and that's an infinite loop.
My suspicion is that the issue relates to enabling YouTube API. For every account, I am able to login to the admin and enable the APIs for my App Script, but I have no way of doing that for the YouTube account. When I enable it for youtube.email#gmail.com, it enables it for the wrong YouTube brand account.
So, I have no idea what's going on. What's the right way to do this? I have tried just writing and deploying the code from the youtube.email#gmail.com account, and I get the same issue.
It sounds like it's because of a known Apps Script issue where it has trouble working when you are logging into multiple Google Accounts - it always uses the default account.
Romain Vialard recently wrote an article about how they get around the issue.

Using Actions on Google and Google Drive together?

I'm a hobbyist student developer playing around with the Actions on Google to create a simple "text adventure" game on Google Home. Since Google Home will be speaking to the player rather than the player reading the text, I'm hoping this will create an experience similar to the "Dungeons and Dragons" roleplaying game, with the computer working as the "Dungeon Master." With the natural language assistance offered by API.AI and Actions on Google, it seemed like a good fit, since the player can respond "naturally." Here's an example of an Amazon Alexa skill that does essentially what I'm going for.
However, every time I boot up the game, it's always a new game. I'd like to store a savegame with the user's previous state in a JSON file hosted on the user's Google Drive -- Since I'm just a student doing this for fun, I don't actually have an official website or anything beyond a free Heroku server I'm running the app from, making storing saves on my end pretty much out of the question.
I've walked through the Google Drive REST quickstart for Node.js, and I've gotten that working in the console just fine. The only problem is in that quickstart, the user has to click a link to authorize the application to read the stuff in their Google Drive account, and I'm not sure how I'd be able to "click a link" and give back an access token via voice on Google Home.
Is there a way to do this via Google Drive? Or is there a better way to provide persistent data between sessions? I don't normally work in web development, so any help would be appreciated.
The bad news is you won't be able to get away from the need for a user to use his web browser to authorise your app to access his Drive.
The good news is that you only need to do this once. When your app requests authoirsation, it should specify "offline", which will result in you being given a refresh token. You should save this somewhere in your database of users. Whenever you need to access the user's Drive, you can use the saved refresh token to request an access token and you're good to go.
You have a few problems that you need to solve here, and while they seem related, they're not as related as you might hope:
You need to get authorization to access a user's Drive space
You need to authenticate the user's Home (so you know this person has come back)
You have to connect the two relationships - so you know what Drive space to use for the Home device that is talking to you
You've found the answers to (1) already, and as noted, you'll need to use a browser for them to authorize you to access their Drive. You'll then store the refresh token and will be able to access it in the future.
But that is only part of the problem. Home does not provide you access to the user's Google account directly, so you'll have to manage your own account mechanism and tie it to Home. There are a few solutions here:
Home provides anonymous user identity in the JSON sent to your webhook. You can access this using getUser().user_id if you're using the Actions API library, or access this in the data.user.user_id field in the JSON. While this is similar to a browser cookie, it only stores the user ID and can't store additional data. There is also no concept of "local storage". On the plus side, this ID is consistent across devices.
You can request user information such as their name and address. But it doesn't have anything unique or account information, so this probably isn't useful to you.
You can implement an OAuth2 server and do account linking. Note that this is the other side from what you need to do with Google Drive - you'll be providing the access and refresh tokens to authenticate and authorize access to your account and the Google Home device will send these tokens back to you so you can determine who the user is. You don't actually need to store account information - you can provide token information using JSON Web Tokens (JWT) or other methods and have them store account information in a secure way. Users will use the Google Home app to actually sign-in to your service as a one-time event.
In order to handle (3), you may be thinking that (1) lets you get tokens and the OAuth solution for (2) requires you to hand out tokens. Can the two be combined? Well... probably, but it isn't as straightforward. You can't just give the Google OAuth2 endpoints to Home - they explicitly block that and you need to control your OAuth2 endpoints. You may, however, be able to build proxy endpoints - but I haven't explored the security implications of doing so.
I think you're on the right track - using Drive is a good place to store users' information. Using Home's account linking gives you a place where they have to come to your web site to authenticate and authorize their Home, and you can use this to do the same for their Drive.

How to select account in Google App Scripts for users with multiple accounts?

For users that are logged into multiple accounts, how can a script let the user pick an account? For example, Gmail, Google Drive, etc. provide a way for the user to select which account to use with a selectable option on the top-right of the page:
How can developers implement a similar mechanism?
There seems to be no way to do that with Google Apps Script libraries - GAS just uses the current primary account. Also, unfortunately, the API Client Library and thus Google Sign-In for websites don't work inside GAS web apps because of the sandbox frame. You could write your own or use some existing OAuth implementation to authenticate with Google but I found a much much simpler solution using Auth0 Lock with only a Google Connection (using the popup method because the redirect method doesn't work within the sandbox frame).
With Chrome Version 70.0.3538.102. You may resolve your issue (at least i did)
Now i make sure i ONLY signed in ONE account at a time. Then use "manage people"
if i have 3 google accounts, i will create 3 people and each time you only have 1 active google account session. With this setup, i ensured everytime my script only execute with my G Suite user instead of #gmail accounts
You can try using the Directory API to work with Apps Script. Retrieve the user using:
GET https://www.googleapis.com/admin/directory/v1/users/userKey.
You can then make an interface that displays the user accounts details(Name, email,etc).

Google Apps Script - Access to different account (contact-api) via OAuth2-authentication

Retrieve/Update Google-Contacts from Apps Script (Spreadsheet)
Environment Desc:
We have a shared spreadsheet belonging to a domain-account "PrimContact" where we also manage our contacts.
The spreadsheet is shared with selected users in the domain with r/w-access.
Workflow so far: after making changes to the spreadsheet persist those changes through script-call.
This api-call was authorized via clientAuth and as of a few days that won't work anymore.
Through clientAuth we were able to allow all the users to manipulate the sheet and finally update
the contacts of the targeted contact (PrimContact).
Problem:
Reading up about deprecation of clientAuth I tried, and somewhat succeeded, to change
authentication to OAuth2. As I understand things there are two ways I can authenticate a
user. Through a clientAccount or via serviceAccount.
SideNote: The following two pages helped a lot in getting it done, especially for serviceAcc.
[1]client account with: https://github.com/googlesamples/apps-script-oauth2
[2]service account auth with: https://github.com/mcdanielgilbert/gas-oauth2-gae
For that to work I added a project to PrimContact-user and created both a web-account and a
service account. Using aforementioned scripts as a starting point authentication works too, but
in the end it's not what I am trying to accomplish.
Client Account: the script is calling the api (contact-api) with an access token for the currently
logged in client although I provided the clientId of the PrimContact-user. Now I COULD run the script as PrimContact-user beforehand and store the token
in the document. If the access-token has not expired yet the other users can work with this
token just fine and therefore "operate" on the PrimContact-data. But as soon as the token
expires I would have to call the script as PrimContact-user again, which is not to very comfortable.
Service Account: got it working with gas-oauth2-gae, but the contact-list is empty. The call
itself is successfull though. I guess this is due to the service account not being tied to
the PrimContact-user although the project is associated with this user?
Goal:
Making an api-call (contacts) inside google-apps-script(spreadsheet) used by different users and
manipulate contact-data of a different account, i.e. the account who originally shared the spreadsheet.
Maybe I'm getting the whole idea of OAuth2 completely wrong, so far my understanding of the
clientAccount-thing is that the currently logged in user allows the project (which belongs to the
PrimContact-user) to manipulate the data of the currently logged in user.
What data the service-account-authenticated call is manipulating.. I'm not quite sure..
If it helps I can add the code-snippets, but as everythings "working" & still not doing what
I really need it to do I'm not sure if it's helpful.

Second authorization with same scope and offline access_type has unexpected permission dialog

If I specify access_type=offline in the auth url and a user attempts to auth a second time I get a box that says it is asking for offline access.
I would have expected it to be already authorised and so not require additional permissions
Any ideas?
Edit:
A bit more info. The first time around it makes no mention to the user of needing offline access. I would have thought the offline permission to be mentioned in the original auth anyway.
Edit 2:
Some more info on my use case. It is possible in our system for a person to have two accounts but then use the same google drive account. This means that we have no way of knowing that user has already authorized with google and so have to present the authorization again for the second user.
The first time around (for user 1) you are told that the app is asking for :
View and manage Google Drive files that you have opened or created
with this app
View and manage the files and documents in your Google
Drive
The second time around (for user 2) you are told the app is asking to:
Have offline access
This seems wrong to me.
As an aside:
The whole "have offline access" statement is very confusing for a user and also quite misleading. Most people assume this means the app can read the contents of your pc. In fact it means that the app can authenticate with your account with out you being there (i.e. using a refresh token).