Assigned
Status Update
Comments
bl...@gmail.com <bl...@gmail.com> #2
Same behavior here.
gk...@google.com <gk...@google.com>
an...@paperculture.com <an...@paperculture.com> #3
Any update on when this issue will be addressed?
da...@gmail.com <da...@gmail.com> #4
Any update on this? Does anyone know of any work arounds?
ju...@gmail.com <ju...@gmail.com> #5
Any feedback/workaround appreciated
gk...@google.com <gk...@google.com> #6
Currently, by design, service accounts are not allowed to access the Execution API. However, we are looking at adding this functionality, and have an internal feature request to address it. Please follow this issue for updates as the work progresses.
[Deleted User] <[Deleted User]> #7
I hit this - it turns out I was having problems because I wasn't setting the `Content-Type` to `application/json`
Also - I sent parameters as an array rather then key value pairs. ie:
headers: {
"Authorization" => "Bearer #{TOKEN}",
"Content-Type" => "application/json"
}
body: {
"function" => "funcName"
"parameters" => [ "param1", "param2"]
}.to_json
Also - I sent parameters as an array rather then key value pairs. ie:
headers: {
"Authorization" => "Bearer #{TOKEN}",
"Content-Type" => "application/json"
}
body: {
"function" => "funcName"
"parameters" => [ "param1", "param2"]
}.to_json
[Deleted User] <[Deleted User]> #8
This is really needed feature, +1
[Deleted User] <[Deleted User]> #9
NEEDED +1
jp...@gmail.com <jp...@gmail.com> #10
+!1!
dm...@gmail.com <dm...@gmail.com> #11
Did I get right, that it is not possible to use Execution API in a mode, when I want server to server script calls and authorization without user intervention?
Google instruction directs using service accounts, right? Is there any other way to call those scripts?
Google instruction directs using service accounts, right? Is there any other way to call those scripts?
ka...@gmail.com <ka...@gmail.com> #12
I think you got it right. Until they add the ability to use service accounts, user involvement is required.
jp...@gmail.com <jp...@gmail.com> #14
I tried this 4 weeks ago with the GAS PHP library – basically as describe in the G+ posting mentioned by Julien above. I was indeed able to get a token and work with it, but as soon as it expired I was not able to get a refresh token. Maybe it was me. I would really be happy to get a feedback here, whether anybody managed to get Service Account tokens working and also to refresh them after one hour.
[Deleted User] <[Deleted User]> #15
In python you could do something like this: (this is untested code, i just ripped bits and pieces from one of my projects)
when the user logs in with his google_id, you store his credentials. When you are ready to execute, you retrieve the credentials to execute your script.
when the token is expired, the google library from python will refresh it for you.
In your handlers:
from oauth2client.appengine import oauth2decorator_from_clientsecrets
decorator = oauth2decorator_from_clientsecrets(
client_secrets,
scope=[
'https://www.googleapis.com/auth/drive ',
'https://www.googleapis.com/auth/documents ',
'https://spreadsheets.google.com/feeds ',
'https://www.googleapis.com/auth/userinfo.email '
], message=missing_client_secrets_message)
class LoginHandler(RestHandler):
@decorator.oauth_required
def get(self):
# store the user credentials so it can be used in deferred jobs
storage = StorageByKeyName(CredentialsModel, google_user.user_id(), 'credentials')
storage.put(decorator.credentials)
print 'stored new credentials: ', decorator.credentials.to_json()
and then from the place where you want to execute a script:
from googleapiclient.discovery import build
import httplib2
def execute_script(google_user_id)
storage = StorageByKeyName(CredentialsModel, google_user_id, 'credentials')
credentials = storage.get()
http = httplib2.Http(timeout=15)
credentials.authorize(http)
script_service = build('script', 'v1', http=http)
script_id = 'M-V25Ed...............GSi'
body = {'function': function,
'parameters': parameters}
response = script_service.scripts().run(body=body, scriptId=script_id).execute()
when the user logs in with his google_id, you store his credentials. When you are ready to execute, you retrieve the credentials to execute your script.
when the token is expired, the google library from python will refresh it for you.
In your handlers:
from oauth2client.appengine import oauth2decorator_from_clientsecrets
decorator = oauth2decorator_from_clientsecrets(
client_secrets,
scope=[
'
'
'
'
], message=missing_client_secrets_message)
class LoginHandler(RestHandler):
@decorator.oauth_required
def get(self):
# store the user credentials so it can be used in deferred jobs
storage = StorageByKeyName(CredentialsModel, google_user.user_id(), 'credentials')
storage.put(decorator.credentials)
print 'stored new credentials: ', decorator.credentials.to_json()
and then from the place where you want to execute a script:
from googleapiclient.discovery import build
import httplib2
def execute_script(google_user_id)
storage = StorageByKeyName(CredentialsModel, google_user_id, 'credentials')
credentials = storage.get()
http = httplib2.Http(timeout=15)
credentials.authorize(http)
script_service = build('script', 'v1', http=http)
script_id = 'M-V25Ed...............GSi'
body = {'function': function,
'parameters': parameters}
response = script_service.scripts().run(body=body, scriptId=script_id).execute()
ka...@gmail.com <ka...@gmail.com> #16
One workaround would be to have some "control message cells" that you manipulate from PHP or Python (like with http://karl.kranich.org/2016/01/16/sheets-api-access-with-php-part-4-editing-cells/ ) and then have Google Apps script triggers that watch for that and run your GAS.
ro...@blomqvist.email <ro...@blomqvist.email> #17
Using the flow for Installed Applications only requires user interaction the very first time (and should the permissions are revoked), after that no user interaction is required. I find this to be sufficient for most scenarios.
pe...@gmail.com <pe...@gmail.com> #18
we also did workaround in permissioning one user with access to the desired spreadsheets to our webapp, and then just use this refresh token. Its a ugly hack and i would love to use service account instead...
jp...@gmail.com <jp...@gmail.com> #19
We also chose that last solution of Peter. But to be precise: In this case there is no token involved. The access is not secure. The URL of the webapp musst be kept secret. Knowing that URL gives access to the spreadsheets (or at least to you scripts that control the spreadsheets). Indeed that link can hardly be guessed and is only used in server to server communication and is not visible to anybody, but I would still not use that solution in a public scenario. Anybody looking for details of this option can find a good start on this posting of Jed Woods: https://medium.com/@silentrant/let-google-chew-the-cud-6ba00584b3d5#.xnj06t2uk
pe...@gmail.com <pe...@gmail.com> #20
I mean i have an oauth client key/secret which our application uses.
Then in an manual process i authorized this application with the required permissions for the script to my user which has access to the desired documents.
The refresh token i got from this manual process i just hardcoded then to use for the the calls to the script whenever needed.
very ugly and stupid manual work involved.
so please make service accounts work....
Then in an manual process i authorized this application with the required permissions for the script to my user which has access to the desired documents.
The refresh token i got from this manual process i just hardcoded then to use for the the calls to the script whenever needed.
very ugly and stupid manual work involved.
so please make service accounts work....
jp...@gmail.com <jp...@gmail.com> #21
Oh, I see. But then you token should expire periodically and your connection will fail until you manually refresh.
ro...@blomqvist.email <ro...@blomqvist.email> #22
As long as you have a refresh token, which you need to get manually the first time, you should be able to get new access tokens without any user interaction.
As long as you have access to some kind of file system / file storage you can just store the refresh token there and request new access tokens from it once every hour, completely transparent to the user. If you read through the Google Authorization documentation long-term access is exactly what refresh tokens and the Installed Application flow should be used for and it works fine. Although it would be nice to have the option of using service accounts, I personally prefer the control over the authorization you get with refresh/access tokens.
As long as you have access to some kind of file system / file storage you can just store the refresh token there and request new access tokens from it once every hour, completely transparent to the user. If you read through the Google Authorization documentation long-term access is exactly what refresh tokens and the Installed Application flow should be used for and it works fine. Although it would be nice to have the option of using service accounts, I personally prefer the control over the authorization you get with refresh/access tokens.
jp...@gmail.com <jp...@gmail.com> #23
Rob, this is what did not work for us. I could not get a refresh token automatically. But it is very well possible that I simply did not find the correct implementation for PHP. General problem is that the information scattered around the web is sparse, partially outdated and/or contradictory and the fact that Google itself promotes the usage of a Service Account that actually does not work (yet) does not make things easier.
ro...@blomqvist.email <ro...@blomqvist.email> #24
You do not get the refresh token automatically - you get that one manually. This is the only time you need user intervention. When you have the refresh token you do not need any other user intervention - the refresh token can be used to continuously get new access tokens for long-term access.
I think the main problem is that people do not understand how and when to use the existing Google auth flows and are waiting for this "one-key-to-rule-them-all" solution, to use in every "headless" situation. It is not a very wise approach.
The flow I use for automated google interactions (some have run 24/7 for months without user interaction)
* Get the refresh token manually.
* Store the refresh token securely.
* Use the refresh token to get an access token.
* Use the access token for your service calls.
* When the access token expires (about an hour) use your previously stored refresh token to get a new access token.
Only the very first step, retrieving the refresh token, requires user interaction. The benefit of this is that ff something goes wrong, just throw away the file with the refresh token and your data is out of reach as soon as the current access token expires. You can always repeat the first step of getting a new refresh token.
With a Service Account you have to enter the Google admin pages and disable the service account, which is messy and could ruin other projects depending on the same service account.
I think the main problem is that people do not understand how and when to use the existing Google auth flows and are waiting for this "one-key-to-rule-them-all" solution, to use in every "headless" situation. It is not a very wise approach.
The flow I use for automated google interactions (some have run 24/7 for months without user interaction)
* Get the refresh token manually.
* Store the refresh token securely.
* Use the refresh token to get an access token.
* Use the access token for your service calls.
* When the access token expires (about an hour) use your previously stored refresh token to get a new access token.
Only the very first step, retrieving the refresh token, requires user interaction. The benefit of this is that ff something goes wrong, just throw away the file with the refresh token and your data is out of reach as soon as the current access token expires. You can always repeat the first step of getting a new refresh token.
With a Service Account you have to enter the Google admin pages and disable the service account, which is messy and could ruin other projects depending on the same service account.
ni...@noovle.com <ni...@noovle.com> #25
NEEDED +1
ry...@google.com <ry...@google.com>
cb...@gmail.com <cb...@gmail.com> #26
[Comment deleted]
cb...@gmail.com <cb...@gmail.com> #27
I could use this for sure. I need to get form responses in an orderly fashion that doesn't revolve around continually extracting the output responses excel sheet. I need to track updates automatically which allows me to do via the app script api.
So, unless forms api is released under the drive api, I would love to have the ability to do this.
+1
So, unless forms api is released under the drive api, I would love to have the ability to do this.
+1
[Deleted User] <[Deleted User]> #28
Jeez, I wish I found this thread earlier. Had so much frustration over this one. I would like it fixed as well :)
ro...@mangoket.com <ro...@mangoket.com> #29
Needed +1
ni...@noovle.com <ni...@noovle.com> #30
What about this library?
https://github.com/googlesamples/apps-script-oauth2
There is a section related to Service Accounts
"...This library supports the service account authorization flow..."
There is a section related to Service Accounts
"...This library supports the service account authorization flow..."
br...@mcpher.com <br...@mcpher.com> #31
That just means that this library is able to generate service accounts. The
problem is not with generating service accounts. The problem is that the
execution API does not accept tokens from service account flows.
problem is not with generating service accounts. The problem is that the
execution API does not accept tokens from service account flows.
sh...@google.com <sh...@google.com> #32
se...@ccsknights.org <se...@ccsknights.org> #33
@35 Sorry this is off topic, but to answer your question the try-it example will not work from the documents page, but you can do it from https://developers.google.com/oauthplayground/ . You can generate OAuth2 credentials in your published Execution API then click the gear at the playground site and select the option 'Use you own OAuth credentials'. You do need to add https://developers.google.com as an authorized origin and https://developers.google.com/oauthplayground as an authorized redirect uri
ni...@noovle.com <ni...@noovle.com> #34
@34 Thank-you for the clarification
jo...@gmail.com <jo...@gmail.com> #35
What's unfortunate about this lack of service account support is that various semi-official Google documentation (the Google dev console, the nodejs package) encourage the use of service accounts (and JWT auth with service accounts), and then one takes some time to implement around that.. only to have to troubleshoot the returned errors and discover that this API doesn't support what was expected.
The issue somewhat straightforward to workaround (if not a little ugly), and then THAT particular developer no longer urgently needs a fix here... but as longer as service account support is missing, I can guess that I won't be the last person to have to go through this. :)
The issue somewhat straightforward to workaround (if not a little ugly), and then THAT particular developer no longer urgently needs a fix here... but as longer as service account support is missing, I can guess that I won't be the last person to have to go through this. :)
be...@flama.fr <be...@flama.fr> #36
Hello,
In the same way I would like to use Apps Script with a service account. Example : USe Gmail.Users.Settings.SendAs.create in Apps Script and run it with a service account that has domain-wide autority.
This would be great
In the same way I would like to use Apps Script with a service account. Example : USe Gmail.Users.Settings.SendAs.create in Apps Script and run it with a service account that has domain-wide autority.
This would be great
[Deleted User] <[Deleted User]> #37
Hi,
So is it still not possible to execute google scripts thru the service account? We're also getting the 404 using .p12 cert and pretty much reproducing .Net code from one of devs's sites... Thanks!
So is it still not possible to execute google scripts thru the service account? We're also getting the 404 using .p12 cert and pretty much reproducing .Net code from one of devs's sites... Thanks!
np...@gmail.com <np...@gmail.com> #38
Hello,
Is there any projected timeframe we can expect this to be delivered as a feature? It appears that loads of folks are attempting to generate and populate data in docs/sheets using google scripts via the service account.
Thank you
Is there any projected timeframe we can expect this to be delivered as a feature? It appears that loads of folks are attempting to generate and populate data in docs/sheets using google scripts via the service account.
Thank you
de...@nicemice.net <de...@nicemice.net> #39
The script execution API is the very first (and so far, only) Google API I've tried to use. I want to call it from a web server running on App Engine. The script does not need access to any user data, it will be a pure function of its parameters (I just want to use the Optimization Service). After learning about the script execution API, and the google-api-python-client library, and default credentials, and putting it all together, the 404 error was very mysterious. None of the docs give any hint that this won't work. The "Using the Execution API" page at https://developers.google.com/apps-script/guides/rest/api even has a "Limitations" section, but it doesn't mention service accounts not working.
ro...@blomqvist.email <ro...@blomqvist.email> #40
#43 Using a Service Account should be your last resort - not your first. I think this is a general problem with app scripts, that people want to use this "easy auth method" since they think the traditional OAuth is difficult or cannot be used without human interaction.
The traditional way of having a refresh token stored somewhere (on disk or in a blob) and use that to get your access tokens is much more secure and works great without human interaction. It does add a small overhead to your code since you need to get a new access token every hour or so but the refresh token will only need to be fetched once.
I have been running Apps Script on headless web servers for a very long time now without any hassle or a single second of human interaction needed with regards to the authentication. All you need to do initally is make sure you have a refresh token stored somewhere and you're good.
I do agree with the documentation about service account limitations is poor.
The traditional way of having a refresh token stored somewhere (on disk or in a blob) and use that to get your access tokens is much more secure and works great without human interaction. It does add a small overhead to your code since you need to get a new access token every hour or so but the refresh token will only need to be fetched once.
I have been running Apps Script on headless web servers for a very long time now without any hassle or a single second of human interaction needed with regards to the authentication. All you need to do initally is make sure you have a refresh token stored somewhere and you're good.
I do agree with the documentation about service account limitations is poor.
re...@gmail.com <re...@gmail.com> #41
#44 I agree that service accounts should not be used in most of the use cases, but I think they have good reasons to be here. In a large organization, running a server app with the account of one of the employees (with a refresh token from his account) does not make sense. He may move to another team, leave the organization, depending on the scopes the service account could have access to his Drive/GMail/Calendar, he may revoke the token anytime with a simple request... There are a lot of maintainability and security issues.
Hence this issue is really a problem in large organizations, although I agree there is a good (undocumented) workaround for individuals. I really hope this can be solved soon.
Hence this issue is really a problem in large organizations, although I agree there is a good (undocumented) workaround for individuals. I really hope this can be solved soon.
st...@noovle.com <st...@noovle.com> #42
Hi
we should have a similar issue:
- to handle auth to our web app through Google token, we create a precise user
- within our web app, we need to call Google API without any interactive connection so we created the service account from the previously-created user
- when we use this service account to call Drive Upload API standard, it's all ok
- when we use this service account to call API script execution, (https://console.developers.google.com/apis/api/script/overview?project=project-id-9167264583422190089&hl=IT ) (custom and distributed as executable API), the result is KO
keep in mind that:
- APIs' Google Apps Script Execution API (https://console.developers.google.com/apis/api/script/overview?project=project-id-9167264583422190089&hl=IT ) 'and' 'Google API Sheets' are enabled for the service account;
- as ID script we tested both "Project Code" and "ID script"
- Anyone can access the script
we should have a similar issue:
- to handle auth to our web app through Google token, we create a precise user
- within our web app, we need to call Google API without any interactive connection so we created the service account from the previously-created user
- when we use this service account to call Drive Upload API standard, it's all ok
- when we use this service account to call API script execution, (
keep in mind that:
- APIs' Google Apps Script Execution API (
- as ID script we tested both "Project Code" and "ID script"
- Anyone can access the script
ed...@gmail.com <ed...@gmail.com> #43
Needed +1
ma...@indowwindows.com <ma...@indowwindows.com> #44
Is there any update on this? Also, thank you for surfacing this, as I was very confused trying to sort out what was happening.
I second the above frustrations. All of the related google documentation suggests using a service account, which I have now taken the time to implement, and which for some (apparently undocumented) reason, does not have the ability to access/run scripts?
My use case requires that no google account or login be entered/approved/viewed by the user, only by the (clientside javascript) application. This appears to be the intended function of the service accounts to begin with, but if I am misunderstanding, does someone have a suggested workaround?
Any help is appreciated, at present I'm afraid I'll have to rewrite/adapt my existing (functional, preferable) google script into a far clunkier, far more bandwidth intensive clientside approach. I'd really rather not.
Thank you.
I second the above frustrations. All of the related google documentation suggests using a service account, which I have now taken the time to implement, and which for some (apparently undocumented) reason, does not have the ability to access/run scripts?
My use case requires that no google account or login be entered/approved/viewed by the user, only by the (clientside javascript) application. This appears to be the intended function of the service accounts to begin with, but if I am misunderstanding, does someone have a suggested workaround?
Any help is appreciated, at present I'm afraid I'll have to rewrite/adapt my existing (functional, preferable) google script into a far clunkier, far more bandwidth intensive clientside approach. I'd really rather not.
Thank you.
mc...@gmail.com <mc...@gmail.com> #45
Needed +1. oAuth refresh token have limit. I would like to use Service Account.
di...@gmail.com <di...@gmail.com> #46
[Comment deleted]
di...@gmail.com <di...@gmail.com> #47
[Comment deleted]
jb...@google.com <jb...@google.com> #48
Here is an Apps Script that calls itself. I don't know if that will help anyone with service accounts, but this does get around the "Invalid JSON payload received" error.
function executeRemoteFunction() {
var params = {
"function": "remote",
"devMode": true,
"parameters": [
"foo", "bar", 6
]
};
var options = {
'method' : 'post',
'payload' : JSON.stringify(params),
headers: {
Authorization: 'Bearer ' + ScriptApp.getOAuthToken(),
"Content-Type": "application/json"
},
muteHttpExceptions: true
};
var response = UrlFetchApp.fetch("https://script.googleapis.com/v1/scripts/ " + ScriptApp.getScriptId() + ":run", options);
// Throw the response, just so we can see it easily.
throw response;
};
function remote(p1, p2, p3) {
return "I got these params: " + JSON.stringify({
p1: p1,
p2: p2,
p3: p3
});
}
function executeRemoteFunction() {
var params = {
"function": "remote",
"devMode": true,
"parameters": [
"foo", "bar", 6
]
};
var options = {
'method' : 'post',
'payload' : JSON.stringify(params),
headers: {
Authorization: 'Bearer ' + ScriptApp.getOAuthToken(),
"Content-Type": "application/json"
},
muteHttpExceptions: true
};
var response = UrlFetchApp.fetch("
// Throw the response, just so we can see it easily.
throw response;
};
function remote(p1, p2, p3) {
return "I got these params: " + JSON.stringify({
p1: p1,
p2: p2,
p3: p3
});
}
jp...@gmail.com <jp...@gmail.com> #49
I have a workaround that involves:
1. Creating an actual google account to use as a "not really a service account".
2. Manually going through the oAuth2 flow with that "not really a service account" the first time you start the service.
3. Caching the oauth2 token in a redis on the server, having it auto refresh when it expires.
Seems to be working well.
Next level is writing a bot that automatically performs the manual approval section of the oauth flow.
Really jankey, but it works.
1. Creating an actual google account to use as a "not really a service account".
2. Manually going through the oAuth2 flow with that "not really a service account" the first time you start the service.
3. Caching the oauth2 token in a redis on the server, having it auto refresh when it expires.
Seems to be working well.
Next level is writing a bot that automatically performs the manual approval section of the oauth flow.
Really jankey, but it works.
dr...@gmail.com <dr...@gmail.com> #50
We were planning to use this as well for creating documents in google drive & then running a script on them to generate/validate content, but getting the "The caller does not have permission" errors as well. In our case the service account just creates a document & shares it with the active user.
my...@gmail.com <my...@gmail.com> #51
+1 I would like to use Service Account.
[Deleted User] <[Deleted User]> #52
how do you auto refresh the token when it expires?
previous:
I have a workaround that involves:
1. Creating an actual google account to use as a "not really a service account".
2. Manually going through the oAuth2 flow with that "not really a service account" the first time you start the service.
3. Caching the oauth2 token in a redis on the server, having it auto refresh when it expires.
previous:
I have a workaround that involves:
1. Creating an actual google account to use as a "not really a service account".
2. Manually going through the oAuth2 flow with that "not really a service account" the first time you start the service.
3. Caching the oauth2 token in a redis on the server, having it auto refresh when it expires.
[Deleted User] <[Deleted User]> #53
this bug is very fustrating
ry...@google.com <ry...@google.com>
[Deleted User] <[Deleted User]> #54
Re: Auto refreshing on expire.
Many oauth libraries (I use golang's) will automatically auto-refresh. However there is a peculiarity with this api that the token is denied on the server about 6 minutes before it actually expires.
Before you use the token, check if it expires within 10 minutes. If it does, refresh the token manually.
If you're still confused, google "Refresh oauth token <MY LANGUAGE>"
Many oauth libraries (I use golang's) will automatically auto-refresh. However there is a peculiarity with this api that the token is denied on the server about 6 minutes before it actually expires.
Before you use the token, check if it expires within 10 minutes. If it does, refresh the token manually.
If you're still confused, google "Refresh oauth token <MY LANGUAGE>"
co...@gmail.com <co...@gmail.com> #55
Still no news?!
so...@gmail.com <so...@gmail.com> #56
+1
ra...@gmail.com <ra...@gmail.com> #57
It's November 2017, where is this feature???
ke...@gmail.com <ke...@gmail.com> #58
+1 I'd like this feature to use for continuous integration to test my local code within the GAS execution environment.
ro...@mangoket.com <ro...@mangoket.com> #59
+1
We need this feature that because when we use user own token to call api on server, that sometimes happen "Authorization is required to perform that action" error message. And we must wait for 2~3 minutes to try again.
We need this feature that because when we use user own token to call api on server, that sometimes happen "Authorization is required to perform that action" error message. And we must wait for 2~3 minutes to try again.
jm...@tele-metron.com <jm...@tele-metron.com> #60
At least explicitly state that this issue precludes the use of a service account to execute the scripts API. It would save a ton of develoment cycles for folks and lower the frustration level with the process.
ia...@uplevelsystems.com <ia...@uplevelsystems.com> #61
+1
Why does the documentation encourage the use of a service account when it clearly doesn't work?
Why does the documentation encourage the use of a service account when it clearly doesn't work?
[Deleted User] <[Deleted User]> #62
Can I clarify that this is still happening with the Scripts API - which I understand was renamed from the 'Execution' API?
It's quite a time sink trying to sort out these authentication issues not knowing there's this brick wall here.
It's quite a time sink trying to sort out these authentication issues not knowing there's this brick wall here.
al...@humny.com <al...@humny.com> #63
Just spent many days trying to call Apps Scripts API via a service account. I just found this bug. Is this for real? Why isn't this immediately obvious in the documentation? Or better yet... Can this be fixed please? Thank you! :)
sa...@saisreenath.com <sa...@saisreenath.com> #64
+1, Had to spend days to get here, clear documentation could have been better. It would be really good to fix this, as for larger organizations, it is going to be key to handle API's with Service Account.
al...@gmail.com <al...@gmail.com> #65
+1 wtf, at least document it!!!
ti...@google.com <ti...@google.com> #66
je...@gmail.com <je...@gmail.com> #67
+1
Don't get me wrong, it's great that you updated one page of the documentation to reach that. But you should add that warning on top of every page of the Google Apps Script API documentation. I have to echo prior sentiments that it is mind-boggling that Google has created service accounts and is pushing to use them, and yet in this situation which clearly calls for service accounts, they do not work. Beyond that, it is disappointing that it has taken three years for this bug to be documented—let alone fixed.
When might we expect this to happen?
Without this feature, it is impossible to seamlessly install Google Apps Scripts without requiring permission dialogs that have no reason to exist (since they do not access user data).
Don't get me wrong, it's great that you updated one page of the documentation to reach that. But you should add that warning on top of every page of the Google Apps Script API documentation. I have to echo prior sentiments that it is mind-boggling that Google has created service accounts and is pushing to use them, and yet in this situation which clearly calls for service accounts, they do not work. Beyond that, it is disappointing that it has taken three years for this bug to be documented—let alone fixed.
When might we expect this to happen?
Without this feature, it is impossible to seamlessly install Google Apps Scripts without requiring permission dialogs that have no reason to exist (since they do not access user data).
du...@gmail.com <du...@gmail.com> #68
+1 this is insane. The process of writing/maintaining/deploying google sheets scripts is already crazy, and this API seems to be the only real way to do it. Why even have the API if we can't access it with a bot?
jh...@bn.co <jh...@bn.co> #69
I can't believe I've followed the documentation and went through days of work just to find out that the most obvious usage of Service Accounts and Google Scripts API don't work together. How has this been an issue for over 3 years? Why is Google pushing Service Accounts if they are functionally worthless in many scenarios?
ri...@zzapps.nl <ri...@zzapps.nl> #70
IT is possible using oauth2 library, the service account Keys and
urlfetchapp to call the rest endpoints.
Op di 29 jan. 2019 22:04 schreef <buganizer-system@google.com:
urlfetchapp to call the rest endpoints.
Op di 29 jan. 2019 22:04 schreef <buganizer-system@google.com:
mh...@gmail.com <mh...@gmail.com> #71
+1
jo...@gmail.com <jo...@gmail.com> #72
Quite ridiculous! My company doesn't pay me to read articles about Google's broken APIs for days. It's unbelievable how much time I wasted on this already.
I'm tempted to look at "Zoho writer" to solve my problem.
I'm tempted to look at "Zoho writer" to solve my problem.
[Deleted User] <[Deleted User]> #73
+1
Are you kidding me? Five days for me to finally figure out the reason it's not working is a 4 years old bug? Unbelievable is the word.
Are you kidding me? Five days for me to finally figure out the reason it's not working is a 4 years old bug? Unbelievable is the word.
po...@gmail.com <po...@gmail.com> #74
+1
ma...@gmail.com <ma...@gmail.com> #75
Still a big problem. Just run into it. Basically a show-stopper.
I don't understand why this is is not supported. 4 years and still no solution
I don't understand why this is is not supported. 4 years and still no solution
ma...@gmail.com <ma...@gmail.com> #76
is there any update on this topic?
tu...@gmail.com <tu...@gmail.com> #77
+1, wasted a couple days just to figure out that this is the issue.
lo...@gmail.com <lo...@gmail.com> #78
+1, It's unbelievable ... made me waste time and money!!!
de...@gmail.com <de...@gmail.com> #79
+1
ku...@gmail.com <ku...@gmail.com> #80
+1
me...@gmail.com <me...@gmail.com> #81
Please help remove all these hacks i have been stalked n hacked fir 3 years by Luc Savage i even found the facebook hack that has his bike name "karana"in it he has control over all my settings
od...@agenceharmonie.com <od...@agenceharmonie.com> #82
Bonjour tout le monde, [Hello everybody]
Comment on fait maintenant ? [How do we play now ?]
Existe t'il au moins une alternative ? [An alternative exists ?]
Comment on fait maintenant ? [How do we play now ?]
Existe t'il au moins une alternative ? [An alternative exists ?]
pj...@gmail.com <pj...@gmail.com> #83
Apparently Google doesn't care if people use Apps Scripts for actual production software or not. This is such an obvious use case if you're doing anything more than personal scripts.
ri...@zzapps.nl <ri...@zzapps.nl> #84
Disagree. Addons for example run on the same auth level.
Op do 10 okt. 2019 02:30 schreef <buganizer-system@google.com>:
Op do 10 okt. 2019 02:30 schreef <buganizer-system@google.com>:
r....@pixel-combo.de <r....@pixel-combo.de> #85
+1
[Deleted User] <[Deleted User]> #86
+1
gc...@160over90.com <gc...@160over90.com> #87
+1
[Deleted User] <[Deleted User]> #88
+1
[Deleted User] <[Deleted User]> #89
+1
ti...@gmail.com <ti...@gmail.com> #90
+1
[Deleted User] <[Deleted User]> #91
+1
ar...@gmail.com <ar...@gmail.com> #92
+1
ga...@gmail.com <ga...@gmail.com> #93
+1 NEEDED
After 2 days of struggle, I find this topic... frustrating
After 2 days of struggle, I find this topic... frustrating
da...@gmail.com <da...@gmail.com> #94
+1
zi...@gmail.com <zi...@gmail.com> #95
+1
sa...@einride.tech <sa...@einride.tech> #96
+1
[Deleted User] <[Deleted User]> #97
this is incredibly disappointing! how unprofessional. I did not expect this from google.
[Deleted User] <[Deleted User]> #98
+1
ma...@gmail.com <ma...@gmail.com> #99
+1
li...@gmail.com <li...@gmail.com> #100
+1
k....@robotiq.com <k....@robotiq.com> #101
Tried for a couple of days to make the App Engine default service account talk to the Chat/Hangouts API with python37. Created a service account key and assigned to GOOGLE_APPLICATION_CREDENTIALS, now the unhelpful "Request had insufficient authentication scopes." is gone. But now I have to manage a secret in App Engine code instead of using the default service account...
mi...@poshmark.com <mi...@poshmark.com> #102
+1
pr...@gmail.com <pr...@gmail.com> #103
+1
ma...@gmail.com <ma...@gmail.com> #104
+1
re...@platform28.com <re...@platform28.com> #105
+1
dm...@gmail.com <dm...@gmail.com> #106
+1 I'm using a service account to make a copy of a base template which has a script. I then share the copy with a user (myself). It seems that the script will not run in the copy because it's owned by the service account.
ph...@gmail.com <ph...@gmail.com> #107
Bump up the priority, insane this is still pending 5 years later
bc...@atlassian.com <bc...@atlassian.com> #108
+1
pe...@gmail.com <pe...@gmail.com> #109
+1
[Deleted User] <[Deleted User]> #110
+1
w1...@apps.losrios.edu <w1...@apps.losrios.edu> #111
Any advice on calling an Apps Script function via a web service (.NET Core 3.1 Web API)???
me...@gmail.com <me...@gmail.com> #112
Looking to create apps script from node js, but the service account doesn't have access... Could the "User has not enabled the Apps Script API" be worked around by logging in as the service account and enabling this api?
ri...@verifiedmetrics.com <ri...@verifiedmetrics.com> #113
+ 1
Looking to setup a CI pipeline that is able to do `clasp push` without sharing (g suite) user's `.clasprc.json` with the CI pipeline.
Looking to setup a CI pipeline that is able to do `clasp push` without sharing (g suite) user's `.clasprc.json` with the CI pipeline.
kh...@gmail.com <kh...@gmail.com> #114
+1
OF...@goguardian.com <OF...@goguardian.com> #115
+1
wo...@move.com <wo...@move.com> #116
+1
ad...@gmail.com <ad...@gmail.com> #117
+1
el...@gmail.com <el...@gmail.com> #118
+1
th...@txture.io <th...@txture.io> #119
Oh no, ... finally ended up here.
Just need to call an apps script with a service account.
+1
Just need to call an apps script with a service account.
+1
sa...@gmail.com <sa...@gmail.com> #120
+1
ol...@gmail.com <ol...@gmail.com> #121
+1
[Deleted User] <[Deleted User]> #122
+1
I really needed this. The fact that this has been open this long shows they do not intend to fix it despite it still being open. It is not a technical limitation. They simply do not care about the valid use cases this prevents, you as a developer, your job, or your product,. If they had any respect for us at all they would have at least given us the full reasoning for this limitation rather than a single warning sentence in the documentation stating it exists (and even that took 3 years of people complaining about it). It's a clear case of "throwing the baby out with the bath water" for whatever theoretical security issue they have decided for us to protect us from that we aren't even allowed to know about. Aligns perfectly to Mommy Googles universal prime directive of prioritizing "Safety™ " over freedom (and overall usability) at whatever cost. Google does not see the developers utilizing API services, even professionally, as equals. They are GOOGLE developers. They are special, they are better than you, and they know the security your app needs more than you do.
I really needed this. The fact that this has been open this long shows they do not intend to fix it despite it still being open. It is not a technical limitation. They simply do not care about the valid use cases this prevents, you as a developer, your job, or your product,. If they had any respect for us at all they would have at least given us the full reasoning for this limitation rather than a single warning sentence in the documentation stating it exists (and even that took 3 years of people complaining about it). It's a clear case of "throwing the baby out with the bath water" for whatever theoretical security issue they have decided for us to protect us from that we aren't even allowed to know about. Aligns perfectly to Mommy Googles universal prime directive of prioritizing "Safety™ " over freedom (and overall usability) at whatever cost. Google does not see the developers utilizing API services, even professionally, as equals. They are GOOGLE developers. They are special, they are better than you, and they know the security your app needs more than you do.
su...@gmail.com <su...@gmail.com> #123
+1 need this
he...@gmail.com <he...@gmail.com> #124
+1
na...@whereby.com <na...@whereby.com> #125
+1
je...@gmail.com <je...@gmail.com> #126
+1
an...@google.com <an...@google.com>
cw...@uber.com <cw...@uber.com> #127
Yup +1
un...@quicksliver.org <un...@quicksliver.org> #128
+1
ka...@gmail.com <ka...@gmail.com> #129
help +1
is...@google.com <is...@google.com>
iv...@wearevolt.com <iv...@wearevolt.com> #130
The issue becomes unassigned few days ago. Could people from Google at least say that the issue is not a bug, this limitation has a cause by design, and it won't be fixed? Hundreds of people waste a lot of time here.
os...@jetbrains.com <os...@jetbrains.com> #131
Comment has been deleted.
ra...@mindtickle.com <ra...@mindtickle.com> #132
Needed
r....@lineopi.ch <r....@lineopi.ch> #133
+1
[Deleted User] <[Deleted User]> #134
+1
bj...@gmail.com <bj...@gmail.com> #135
+1
ta...@gmail.com <ta...@gmail.com> #136
+1
jo...@gmail.com <jo...@gmail.com> #137
+1
[Deleted User] <[Deleted User]> #138
+1
pr...@gmail.com <pr...@gmail.com> #139
+1
jf...@lumenad.com <jf...@lumenad.com> #140
+1
[Deleted User] <[Deleted User]> #141
+1
da...@gmail.com <da...@gmail.com> #142
+1
wh...@gmail.com <wh...@gmail.com> #143
+1
ma...@gmail.com <ma...@gmail.com> #144
Comment has been deleted.
jo...@giantswarm.io <jo...@giantswarm.io> #145
A huge omission: this is direly needed for simple GApps automation.
ma...@ext.adeo.com <ma...@ext.adeo.com> #146
+1
me...@doubleverify.com <me...@doubleverify.com> #147
Comment has been deleted.
th...@gmail.com <th...@gmail.com> #148
Stumbled on another bug that, even though it might not be directly related, still ends up making you want to pull out your hair:
https://issuetracker.google.com/issues/267033057
pe...@gmail.com <pe...@gmail.com> #149
+1 -- It's only been 7.5 years :)
sh...@talon.one <sh...@talon.one> #150
+1
pr...@gmail.com <pr...@gmail.com> #151
+1
jp...@google.com <jp...@google.com>
jp...@gmail.com <jp...@gmail.com> #152
Assigned after 8 (!) years. Thumbs up!!!
ya...@meta.com <ya...@meta.com> #153
Any updates on this?
hu...@gmail.com <hu...@gmail.com> #154
+1
jp...@google.com <jp...@google.com> #155
Sorry, there are no updates on this feature request, however, I am working to surface requests like these to the product teams for consideration.
In the meantime, if you have a workspace account, you can create an OAuth client and use a refresh token for making calls from non-interactive workflows. See
po...@gmail.com <po...@gmail.com> #156
+11111111
This unworking functionality (hard to call this a "bug" for 8 years already) is an extreme shame. Wasted two days to make a server-server flow with Google Apps Script and still nothing.
This unworking functionality (hard to call this a "bug" for 8 years already) is an extreme shame. Wasted two days to make a server-server flow with Google Apps Script and still nothing.
az...@virtru.com <az...@virtru.com> #157
+1
Description
not already been reported.
Please provide a short description of the issue:
It seems that Execution API doesn't work with Service Account Oauth. Is this by design? if so the reported error behavior is very strange.
The token seems to be valid and properly scoped, since I don't get a 401 error.
I get two kinds of errors
- this one if I include parameters.. (there's nothing wrong with the parameters - i get the same error regardless of what i use for parameter types..
{
"error": {
"code": 400,
"message": "Invalid JSON payload received. Unknown name \"parameters\": Cannot bind query parameter. 'parameters' is a message type. Parameters can only be bound to primitive types.",
"status": "INVALID_ARGUMENT",
"details": [
{
"@type": "
"fieldViolations": [
{
"description": "Invalid JSON payload received. Unknown name \"parameters\": Cannot bind query parameter. 'parameters' is a message type. Parameters can only be bound to primitive types."
}
]
}
]
}
And this one if I don't include parameters.
[15-10-23 10:51:27:191 BST] {
"error": {
"code": 404,
"message": "Requested entity was not found.",
"status": "NOT_FOUND"
}
}
The target script is published as an API executable, and works ok when I use a regular OAUTH2 token from a server application.
Please provide a small sample script that reliably reproduces the issue.
The sample should run as-is or with minimal setup, without external
dependencies.
The code is a little large to reproduce here since it contains code to create service account token as well.
It can be found here
What steps will reproduce the problem?
1. get a service account and download the json
2. change the fileid to the service account drive file
3. run testexecutionAPI
What is the expected output? What do you see instead?
errors as above...
What is the project key (found under "File > Project properties")? The
project key does not give the Apps Script team access to your source
code or data. We use it to look up debug information about your script.
M-dipVp-nmaoC2XRYyy9nIiz3TLx7pV4j
Please provide any additional information below.
The payload seems valid -- with parameters
UrlFetchApp.fetch([
without parameters ---
UrlFetchApp.fetch([
To subsequent readers: If you are also experiencing this issue, please
click the star next to the issue number. We prioritize issues with the
most stars.