I am working on a .NET Google Drive app with scope drive.file. My app does not show up the list of shared files through the query Q = sharedWithMe. However, when I change my app's scope to drive the list of files appears. Why does it not work when the scope is set to drive.file? I created another project on Drive console and tested it but again it failed.
The Drive.Files scope states it only gives access to files opened or created by the app. The new API is more restrictive of file scope, I believe because Google is trying to push dev's to use the new google file picker (as a security measure), to get access to files not created by the app.
Your solutions are:
use the Google file picker.
use the previous api, and use a broader scope.
share explicity with app (#pinoyyid answer), e.g. by creating an application owned account.
Update: I just tested, and can confirm your results. "Created by application" is not an attribute shared between accounts. It only affects the original account.
drive.file can only see files that were created with the app, or explicitly shared with the app. Sharing a file with the user is not enough, it needs to be shared with the app also.
with Drive.File scope, each individual user needs to authorize your app to see the file.
Thus, if you share the file, the user its shared with needs to explicitly open the file with your app in order for you to view it in that context.
In my experience, drive.file scope permissions seem inconsistent.
For example (all actions are performed by the app with drive.file scope):
userA creates a folderA (using files.insert)
userA creates a file inside folderA called fileA (using /upload/drive/v2/files)
userA shares folderA and fileA with userB (using permissions.insert)
userB can see information about both folderA and fileA (using files.get) (So app on UserB account has access to both the folder and the file)
if userA runs children.list on folderA or files.list with q:folderA in parents, it will show fileA
if userB runs the same command it will not show fileA
I apologize for complexity of the above example, I can setup a simple javascript demo if that would be helpful.
I could not find anywhere in Google Drive documentation that claims any restrictions about accessing application created files on different accounts, so it might be a bug introduced trying to solve scope violation bugs last year.
For example:
List ignores drive.file scope and shows shared files not created by the calling app
Related
I need to edit Google Drive files created with my nodeJs webapp and owned by me or shared with me.
Using "https://www.googleapis.com/auth/drive/file" scope I can edit files owned by me.
To edit also files shared with me I must use "https://www.googleapis.com/auth/drive" scope. But this scope sends a very scary message to users on login: "This wil allow xxx to: see, edit or delete all of your Google Drive files" (bold is mine).
I don't want to delete your files and I don't want to edit all of your files: is there a way to reach my goal with a less scary scope?
The only alternative to the drive scope, if you want to edit the files, is drive.file, which gives access to files that you have opened or created with the app (ref).
Since this is not an option for you, I'm afraid you'll have to use the scary scope.
Feature request:
Considering your situation, I think you might be interested in this Feature Request, regarding the possibility to restrict access to a specific folder. I think that could be very useful for you if it got implemented. I'd suggest you to star that issue, both to keep track of its development and to help prioritize its implemenation:
Drive Restrict access to folder when authorizing applications
Related:
Google Drive API: 404 when accessing file someone else created
Google Sheet OAuth scopes to only access a few files?
I am building an app that functions as a markdown editor, and have Google authentication / login functioning. I have users asking if they can choose to have their documents save to their google drive rather than to my servers, which seems to work fine via the Google Drive v3 API, saved to the app data folder.
However, users are also able to generate a collaborator link for others to visit and which allows them to edit the files as co-owners. I would like to maintain this sharing capability with the Google Drive files, but this (very old) answer suggests that sharing in this way may not possible with files in appdata, because:
Appdata content is supposed to be exclusive to the application.
Does this mean that, as long as my users all access these files exclusively via the app, sharing appdata between users is possible? Or is the appdata folder exclusive to the application and the user? If so, is it at least possible to share editor access to google drive files created by my app but outside the appdata folder?
I'm imagining this process:
User1 creates a file in my app and then my app saves it to his Google Drive (preferably in appdata)
User1 generates a collaborator link via my app, gives it to User2
User2 visits the link which opens User1's file within my app, edits it
User2's edits are saved, and my app updates the original User1's file via the API
Question:
"Or is the appdata folder exclusive to the application and the user?"
Answer:
Yes, it is exclusive for your app on their Drive.
Notes:
Use the AppData folder for Application Data, not User Data.
If the file is created by your app, and you want to store it in the user's Drive, you can use the https://www.googleapis.com/auth/drive.file scope. You app will always have access to that file because it was created by it.
Keep in mind that if your app requires restricted scopes you will have to go through verification.
I want to make my application use a limited scope in Google Drive, namely drive.file.
With this scope if I want to create a new file in the drive, by copying an existing file from another user, which has the permission 'anyone with the link' as read, the copy fails.
This has already been asked a few years ago, but the possibilities seems to have narrowed since, as the suggestion of an application owned account seems now deprecated : all links on application owned accounts are broken.
Question: Is there a means of having an application using the limited scope drive.file, while still creating its files by copying them from a file shared for reading, using some sort of service account ?
Try adding read-write access to file metadata by authorizing with the following scopes:
https://www.googleapis.com/auth/drive.metadata
https://www.googleapis.com/auth/drive.metadata.readonly
This related SO post suggests the same.
Is there a way to get sandboxed, user-selected directory access on any major file service without first getting read level access to their entire filesystem?
There's a lot of talk about "unhosted" static webapps that allow users to access their data from a 3rd party file service (Google Drive, Dropbox, their own server, etc.). The most notable effort I've found so far is remoteStorage.io, but there doesn't seem to be a way with any major provider to let the user select a directory and then use that as a sandbox without breaking their trust (i.e. getting read access to all their files first).
From the user's perspective, the webapp shouldn't have access to anything else on the remote file storage except the one folder the user grants it access to (for example, I might grant a text editor access to my FunnyJokes folder).
The current work around seems to be having the webapp force a specific folder name ahead of time ("this app wants access to /appname_notes"), but that rules out letting the user point it to where they may already have their notes.
Does anyone know of a nice way to do this with Google Drive, Dropbox, or the like?
The user experience that makes the most sense to me is something like...
User opens an unhosted webapp (for example, a basic text editor TextyApp). They click a button to connect with their data.
3rd party auth page appears (for example, Google Drive) and it says "The app TextyApp has requested read/write access to your files. Please select a directory to use."
Confirmation screen: "Grant read/write access to folder FunnyJokes for TextyApp?"
The page redirects back to the webapp with sandboxed accessed to the user-specified folder and the files within it.
This seems like how remote file storage should work, but I haven't found a way to do it yet. Any thoughts/suggestions would be great!
Cheers,
Adam
Edit: To clarify, I'm not talking about storing hidden "application data", but instead letting the user specify a particular directory to sandbox for use with a webapp that they may not want to give broader access to.
The Dropbox Apps API provides the ability to restrict any app using your API key to a single directory of your Dropbox account. So users could create an API key with access to a specific directory and then plug that into your app. However, that's not a user-friendly workflow.
I think the Dropbox Drop-Ins Chooser/Saver API might be close to what you want. The user is presented with a Dropbox file selection popup, and your app only gets access to the specific file(s) that the user selects.
With remoteStorage, sandboxed directory access is currently the default way for apps to request (and users to grant) access to the storage. However, users cannot manually select or enter custom directories during the connect phase.
We are having issues where sometimes a file that a user can access is not returned when the user issues a files.list. This can happen in many ways. For example, new members of a Google group will not see previously shared files, as described in this question. Moreover, acording to Google documentation there are other limits on sharing which can prevent shared files from appearing in the "Shared with me" view. Finally, a user can issue a files.delete on a file she doesn't own, and the file will disappear from files.list but will still exist.
What can a user do via the SDK alone to cause a file which she can access via files.get to appear in the list of files retrieved via files.list? We are using a service account which impersonates users; the user never authenticates to Google via a browser. A link in an email that the user needs to click won't work for us, unfortunately. Accessing the file via the Google Drive UI has the desired effect, but the analogous files.get call does not.
The Google Calendar API explicitly exposes a CalendarList interface where a user can issue an insert to add an existing calendar to her list. The Google Drive SDK seems like a hybrid Files/FilesList interface with some of the functionality missing (nothing like FilesList.insert) and some of the functionality mixed together (issuing a delete as a non-owner acts like FilesList.delete but issuing it as the owner acts like Files.delete).
If we can't manage the user's files list programmatically then it is not useful for our service. We could ignore the files.list call entirely and just start recursively performing children.list queries on all shared folders, but this is incredibly expensive (unless someone knows how to issue a single query which returns all the Files resources in a folder and not just the IDs of those resources).
Any help would be appreciated. We've been trying this many different ways and have been frustrated at every turn. Thanks!