Accessing previously created folder with oauth Google Drive

user_3495792 0
Viewed 195

We are building an app that allows users to connect their cloud storage (in this case gDrive) and upload files from our app, however they also have the ability to disconnect from it and perhaps connect to another.

A use-case might be:

A User connects to gDrive(App creates folder and uploads files) > Later user disconnects from drive in-app > Later user reconnects

Problem being we then want to grab this previously created folder and make changes and the issue is, in order for the user to reconnect they have to reauthorize, setting a new token and we therefore no longer have access to that folder and instead our app auto-creates a new folder with the same name - obviously this is not what we want.

The only solutions we can think of is not re-authorizing on disconnect/connect or increasing the scope of oauth and searching for the folder.

We will be using something like rClone in the future, but for now we are focusing on a couple of the main cloud services.

Are there any other solutions to this?

google-drive-api oauth-2.0 google-oauth
1 Answers
  • Your app is using drive.file scope, which allows it to access files created or opened by the app.
  • Users commonly disconnect from the app, effectively deauthorizing it. Because of this, the app does not have access to folders that were created last time user connected to the app.

The description of drive.file scope is quite clear:

Per-file access to files created or opened by the app. File authorization is granted on a per-user basis and is revoked when the user deauthorizes the app.

Because of this, unfortunately, the only two ways to allow the app to access previously created folders are the ones you already sketched:

  • Use a scope that provides a wider access: the scope in this case should probably be https://www.googleapis.com/auth/drive, since the app, from what I understand, needs write access.
  • Change the workflow of your app so that users don't deauthorize the app.

Regarding the use of a wider scope, the following feature request, which apparently was internalized recently, could provide an acceptable workaround in case it got implemented:

I'd suggest you to star the referenced issue, to keep track of its development and to help prioritizing it.

user_106120110
Related