5

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.

seanpj
  • 6,735
  • 2
  • 33
  • 54
  • Is it your expectation that files created prior revoked authorization will be available at re-authorization with the drive.file scope? – Arthur Thompson May 18 '15 at 23:46
  • 1
    Absolutely. I (a user of an app) have thousands of files created by the app. Then he/she/I plays with the 'Disconnect from drive'. After launching the app, it asks to re-authorize access to files the app created. And OOPS, nothing's there anymore. The FILE scope says 'objects created by this app'.. – seanpj May 19 '15 at 01:13
  • I agree that's a bad experience. We're discussing updating the disconnection dialog and app scope text to clarify behavior. – Daniel May 20 '15 at 06:35
  • @Daniel Can you, please look at [this](http://stackoverflow.com/questions/33248420/invalid-parent-folder-error-for-appfolder-in-drive-api)? – seanpj Oct 22 '15 at 16:02
  • @seanpj I also same similar problem as you do. If I manually disconnect my app from appfolder, GDAA will never pop up http://i.imgur.com/1jJPkiS.png again. Even if I uninstall the app, clear cache and reinstall again, Google drive permission request dialog just won't shown. Hence, it always fail. Unlike GDAA, REST API will show http://i.imgur.com/1jJPkiS.png automatically. – Cheok Yan Cheng Jan 13 '16 at 17:07

1 Answers1

3

The first issue is:

  1. A user revokes authorization via: Settings > Manage Apps > Disconnect From Drive
  2. Then reauthorizes that App
  3. 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.

Matt
  • 46
  • 1
  • 2
  • Good to know, thanks. Even though unlikely event, it will happen to developers during testing. The other scenario, a FILE scope product under 'playful' user's attack could be handled by user education in the dialog Daniel mentioned in his comment. – seanpj May 20 '15 at 09:26
  • Matt, I don't know if you are an insider, but there is another similar problem in [SO 33248420](http://stackoverflow.com/questions/33248420/invalid-parent-folder-error-for-appfolder-in-drive-api). Any ideas? – seanpj Oct 22 '15 at 16:00
  • @Matt, my testing shown that if REST API is used, i.imgur.com/1jJPkiS.png will re-pop up again when "revokes authorization" had done. However, if GDAA is used, i.imgur.com/1jJPkiS.png is never shown again. Hence, drive operation always failed. – Cheok Yan Cheng Jan 14 '16 at 04:10