I've run into this issue a few times, but could never point my finger on it, attributing it to GDAA's latency, my buggy code, etc... I finally managed to come up with a scenario where I can safely reproduce it, so I would like to ask people who know if it is a feature I don' understand or a plain bug. If latter is the case, please point me to the place where I can nag about it.
I will discuss it on the REST API's background for simplicity.
1/ Let's have a Drive API authenticated app that runs under DRIVE_FILE scope
com.google.api.services.drive.Drive svc =
new Drive.Builder(
AndroidHttp.newCompatibleTransport(),
new GsonFactory(),
GoogleAccountCredential
.usingOAuth2( context, Collections.singletonList(DriveScopes.DRIVE_FILE))
).build();
2/ create a file (files/folders) in Google drive using
svc.files().insert([METADATA], [CONTENT]).execute();
3/ search for the objects you've created using
svc.files().list().setQ([QUERY]).setFields([FIELDS]).execute();
When the app is run, user goes through the usual Account-Pick / Drive-Authorize routine and everything works as expected. Files are created, visible, can be found ... until a user revokes the authorization by means of
Settings > Manage Apps > Disconnect From Drive
in drive.google.com.
After that, if the Android app is restarted (and re-authorized), none of the objects created prior the revocation is visible.
It may be by design, I don't know. If this is the case, I can't find a way how the Android app can get to anything it created before. I could certainly create another 'maintenance' app with DRIVE scope to fix this, but...
Now, in case of GDAA, it gets even worse. Not only GDAA does not have the DRIVE scope to fix it, but if the same sequence of steps is done and the app creates a file/folder immediately after revocation, GDAA does not complain, but the file/folder is not created at all. After a while (minutes), the re-authorization pops-up, but still, the files created meanwhile are nowhere to be found and everything pre-dating the revocation is lost to the (creator) app as well (it certainly is visible in the web app that obviously has DRIVE like scope).
Thank you for you patience.
The first issue is:
A user revokes authorization via: Settings > Manage Apps > Disconnect From Drive
Then reauthorizes that App
Files this App was authorized to see with DRIVE_FILE scope are no longer authorized.
This is the expected behavior of the REST and Android APIs.
We don't think users would intuitively expect all previously authorized files to be re-authorized. The user may not remember the files that were previously authorized, and informing users that these files are going to be authorized again will likely cause confusion.
The second issue is GDAA's behavior for folder creation in this situation. We don't currently support CompletionEvents for folder creations, but this is something we'll look into.
Related
I'm trying to write a Python program that uses Google Drive to do some custom backup and sync work from my Linux desktop.
I started using the PyDrive2 library, and followed its recommendations on how to sign up for Drive API access. When I run my program, it accesses Drive as I'd expect it to, but my authorization expires after a few hours, which is not going to work for a program that runs in cron. I thought this might be because my app is not verified, so I looked into verification, but it's asking for things like a my application's home page. Mine isn't a web-based application, so I don't have one.
Is there a good way to access Google Drive APIs from a non-web application?
if your access is expireing after only a few hours it sounds like you are not requesting offline access and storing the refresh token for later use.
If you followed Quickstart pyton You may have noticed this section. The users credetinals that being the refresh otken and the access token are stored in token.json for future use by your application.
# The file token.json stores the user's access and refresh tokens, and is
# created automatically when the authorization flow completes for the first
# time.
if os.path.exists('token.json'):
creds = Credentials.from_authorized_user_file('token.json', SCOPES)
I thought this might be because my app is not verified, so I looked into verification, but it's asking for things like a my application's home page.
Your application only really needs to be verified if you are going to have other uses using it. If your only using it yourself then you really only need to remove it from testing phase and put it into production then your refresh tokens will last longer then seven days.
You could try to use a service account but i don't know of anyone who has gotten service account authorization to work with curl.
I am trying to run
this simple Google Script.
However, it does not allow me to authorise. How can I proceed?
Update 1:
As reported by
Rubén, Google says it won't fix this - #163
Some workarounds are provided in #76, #145 and #150 - showing solutions like changing GCP and providing a oauth consent screen.
Update:
Switching Google cloud project from default to a standard project have resolved the issue for some users. This is still a workaround and may not work for all. Therefore, star the issue below.
This seems to be a new issue affecting certain users. You can ★(on top left) star the issue here to let Google developers know that you're affected by this issue and to prioritize the issue.
It stopped complaining once I specified the script only needed access to the current sheet. Google explains how to do it here.
All you need to add to your code is this JsDoc annotation:
/**
* #OnlyCurrentDoc
*/
That's something that happens. To solve the issue just copy the contents of your Script, delete it, and create a brand new one with the same contents, or give it another name in case you are superstitious. If that doesn't work, create another Spreadsheet with the same contents and proceed. Sometimes it's just a temporary issue. Perhaps the problem persists due to the stored browsing data, so it would be convenient to clear it. (I challenge you to take this last move!)
After going through the process twice with a client, I can confirm that the most reliable way to fix the error currently is to go through the verification process. An important note is that after approving the scopes, some accounts need to approve every other sensitive scope that is added to the script and cloud project as well or the issue will resurface.
So the step-by-step guide is as follows:
Switch from default to standard Google Cloud Project
Fill in the OAuth Credentials screen and add all sensitive scopes
Click on "Submit for verification" and prepare a YouTube video showing both authorization process and usage of each of the sensitive
scope
Wait until the verification team sends you an email (usually 1-2 days, but no guarantee here) and reply with the link to the video, then wait for the verification process to complete
If you received a "Granted" response, continue to steps 6 & 7, if not - follow the instructions provided
Remove all previously granted permissions to the project
Reauthorize the script by running it again, everything should be working
Having the same issue no solution of listed in this thread were working for me. After faied authentification i always get the screen as the topic starter gets it, without the "advanced" option.
However i've managed to get at least a limited access and run my script on the following way:
I share the affected sheet to anybody with link, with editor access level.
Then, from incognito window (maybe it isn't necessary, but i did it so), I've logged in into my other Google account,
opened the link, which was shared,
was forced to authorize myself,
failed on authorization - but the screen with failed authorization contains the "advanced" option,
clicking on it i've got a limited access and was able to run the script.
I am trying to run
this simple Google Script.
However, it does not allow me to authorise. How can I proceed?
Update 1:
As reported by
Rubén, Google says it won't fix this - #163
Some workarounds are provided in #76, #145 and #150 - showing solutions like changing GCP and providing a oauth consent screen.
Update:
Switching Google cloud project from default to a standard project have resolved the issue for some users. This is still a workaround and may not work for all. Therefore, star the issue below.
This seems to be a new issue affecting certain users. You can ★(on top left) star the issue here to let Google developers know that you're affected by this issue and to prioritize the issue.
It stopped complaining once I specified the script only needed access to the current sheet. Google explains how to do it here.
All you need to add to your code is this JsDoc annotation:
/**
* #OnlyCurrentDoc
*/
That's something that happens. To solve the issue just copy the contents of your Script, delete it, and create a brand new one with the same contents, or give it another name in case you are superstitious. If that doesn't work, create another Spreadsheet with the same contents and proceed. Sometimes it's just a temporary issue. Perhaps the problem persists due to the stored browsing data, so it would be convenient to clear it. (I challenge you to take this last move!)
After going through the process twice with a client, I can confirm that the most reliable way to fix the error currently is to go through the verification process. An important note is that after approving the scopes, some accounts need to approve every other sensitive scope that is added to the script and cloud project as well or the issue will resurface.
So the step-by-step guide is as follows:
Switch from default to standard Google Cloud Project
Fill in the OAuth Credentials screen and add all sensitive scopes
Click on "Submit for verification" and prepare a YouTube video showing both authorization process and usage of each of the sensitive
scope
Wait until the verification team sends you an email (usually 1-2 days, but no guarantee here) and reply with the link to the video, then wait for the verification process to complete
If you received a "Granted" response, continue to steps 6 & 7, if not - follow the instructions provided
Remove all previously granted permissions to the project
Reauthorize the script by running it again, everything should be working
Having the same issue no solution of listed in this thread were working for me. After faied authentification i always get the screen as the topic starter gets it, without the "advanced" option.
However i've managed to get at least a limited access and run my script on the following way:
I share the affected sheet to anybody with link, with editor access level.
Then, from incognito window (maybe it isn't necessary, but i did it so), I've logged in into my other Google account,
opened the link, which was shared,
was forced to authorize myself,
failed on authorization - but the screen with failed authorization contains the "advanced" option,
clicking on it i've got a limited access and was able to run the script.
I am trying to run
this simple Google Script.
However, it does not allow me to authorise. How can I proceed?
Update 1:
As reported by
Rubén, Google says it won't fix this - #163
Some workarounds are provided in #76, #145 and #150 - showing solutions like changing GCP and providing a oauth consent screen.
Update:
Switching Google cloud project from default to a standard project have resolved the issue for some users. This is still a workaround and may not work for all. Therefore, star the issue below.
This seems to be a new issue affecting certain users. You can ★(on top left) star the issue here to let Google developers know that you're affected by this issue and to prioritize the issue.
It stopped complaining once I specified the script only needed access to the current sheet. Google explains how to do it here.
All you need to add to your code is this JsDoc annotation:
/**
* #OnlyCurrentDoc
*/
That's something that happens. To solve the issue just copy the contents of your Script, delete it, and create a brand new one with the same contents, or give it another name in case you are superstitious. If that doesn't work, create another Spreadsheet with the same contents and proceed. Sometimes it's just a temporary issue. Perhaps the problem persists due to the stored browsing data, so it would be convenient to clear it. (I challenge you to take this last move!)
After going through the process twice with a client, I can confirm that the most reliable way to fix the error currently is to go through the verification process. An important note is that after approving the scopes, some accounts need to approve every other sensitive scope that is added to the script and cloud project as well or the issue will resurface.
So the step-by-step guide is as follows:
Switch from default to standard Google Cloud Project
Fill in the OAuth Credentials screen and add all sensitive scopes
Click on "Submit for verification" and prepare a YouTube video showing both authorization process and usage of each of the sensitive
scope
Wait until the verification team sends you an email (usually 1-2 days, but no guarantee here) and reply with the link to the video, then wait for the verification process to complete
If you received a "Granted" response, continue to steps 6 & 7, if not - follow the instructions provided
Remove all previously granted permissions to the project
Reauthorize the script by running it again, everything should be working
Having the same issue no solution of listed in this thread were working for me. After faied authentification i always get the screen as the topic starter gets it, without the "advanced" option.
However i've managed to get at least a limited access and run my script on the following way:
I share the affected sheet to anybody with link, with editor access level.
Then, from incognito window (maybe it isn't necessary, but i did it so), I've logged in into my other Google account,
opened the link, which was shared,
was forced to authorize myself,
failed on authorization - but the screen with failed authorization contains the "advanced" option,
clicking on it i've got a limited access and was able to run the script.
I would like to make a copy of a Google Spreadsheet file between users that are not on the same domain. The source file has a sharing setting of Anyone with the link can edit.
I created a Web App (with execution permissions set to User accessing the web app) that call an install function:
I was hoping the code would read the source file which is open to everybody and make a local copy to the Google Drive of the user running the Web App (of course assuming the user accept to run the script). The behavior works when it's me running it (because I am the owner of the source) but do not work if the user is from another domain.
Any suggestions on how to achieve this?
function doInstall() {
// The source file is readable by everybody with the link;
var file = DocsList.getFileById('0AlVPTKz1xoevdHc1ZTQ2OGFMXXXXXXXYYYYZZZZ');
file.makeCopy('Test Copy Spreadsheet');
}
I had a different but similar use case and problem. Like you, my source file was accessible to anyone with the link and my domain settings allowed users to share content outside my domain. It worked for me but not for them.
This might work for you, it has for me (so far):
Assuming you have your original script...
Create a separate script for 'Script as web app'.
Write a function (e.g. loadFileIds()) to store the necessary fileIds using ScriptDb. Run the loadFileIds() function.
Write another function (e.g. getFileId()) in the same project that returns your desired file Id from ScriptDb.getMyDb when called. Avoid using DocsList in this function. I originally thought that because getFileId() would 'run as me' that it would be OK but it was always the DocsList line that caused failures when other users triggered the script.
In File > Manage Versions: Save a version of the project.
Under Publish: Deploy that version of your project as a web app. Choose Execute the app as "me(me#mydomain.com)" and set Who has access to the web app to "Anyone".
In your original project go to Manage Resources and enter the Project Key of the web app, choose a version and copy the identifier.
Write a function that calls yourIdentifier.getFileId() and - hopefully - returns the fileId.
In my experience so far external users have been able to access files that they could not when DocsList methods returned null. But there is one more thing to add... You might find you have to share your web app script with your users. I haven't quite made certain that's necessary but I've encountered bugs when I don't. I untick the option to email them the link.
I learned how to do this from examples in the documentation, this video and of course StackOverflow.
As you can see, I'm still working this out myself and testing of the system has so far been just me simulating other users. So no promises. Good luck! I'll star your issue.