Assigned
Status Update
Comments
sh...@gmail.com <sh...@gmail.com> #2
Same behavior here.
wi...@gmail.com <wi...@gmail.com> #3
Any update on when this issue will be addressed?
ge...@gmail.com <ge...@gmail.com> #4
Any update on this? Does anyone know of any work arounds?
ma...@torontomu.ca <ma...@torontomu.ca> #5
Any feedback/workaround appreciated
ma...@novack.com.ar <ma...@novack.com.ar> #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.
co...@gmail.com <co...@gmail.com> #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
an...@google.com <an...@google.com> #8
This is really needed feature, +1
an...@google.com <an...@google.com>
is...@google.com <is...@google.com>
ma...@novack.com.ar <ma...@novack.com.ar> #9
NEEDED +1
ha...@gmail.com <ha...@gmail.com> #10
+!1!
el...@hudson-trading.com <el...@hudson-trading.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?
el...@hudson-trading.com <el...@hudson-trading.com> #12
I think you got it right. Until they add the ability to use service accounts, user involvement is required.
el...@hudson-trading.com <el...@hudson-trading.com> #13
jk...@gmail.com <jk...@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.
nw...@detroitsci.com <nw...@detroitsci.com> #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()
ma...@novack.com.ar <ma...@novack.com.ar> #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.
nw...@detroitsci.com <nw...@detroitsci.com> #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.
js...@primary.com.ar <js...@primary.com.ar> #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...
gb...@gmail.com <gb...@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
es...@gmail.com <es...@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....
mi...@gmail.com <mi...@gmail.com> #21
Oh, I see. But then you token should expire periodically and your connection will fail until you manually refresh.
an...@gmail.com <an...@gmail.com> #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.
su...@gmail.com <su...@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.
la...@gmail.com <la...@gmail.com> #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.
jp...@google.com <jp...@google.com>
an...@gmail.com <an...@gmail.com> #25
NEEDED +1
aa...@gmail.com <aa...@gmail.com> #26
[Comment deleted]
jp...@google.com <jp...@google.com>
jp...@google.com <jp...@google.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
su...@gscrd.com.br <su...@gscrd.com.br> #28
Jeez, I wish I found this thread earlier. Had so much frustration over this one. I would like it fixed as well :)
ma...@novack.com.ar <ma...@novack.com.ar> #29
Needed +1
jp...@google.com <jp...@google.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..."
Description
> a websocket api
What is the purpose of this new feature?
> support websocket connections
What existing Apps Script services would this affect?
> none
What existing data does this use?
> maybe it could be a part of
Please provide any additional information below, including the particular use cases you believe this feature would enable or improve.
> same kind of feature for