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.
Related
I'm looking to switch all domain-shared files from "Shared with Domain" to "Shared with group". I'm trying to identify whether a permission on a GDrive file (not from Shared Drive) is inherited or not. However Drive V3 API does not appear to expose permissions/permissionDetails attribute in same way as Shared Drives. Is there an efficient way to get the "inherited" status of a permissions? Trying to avoid having to walk the folder hierarchy.
Background on use case: We have decided that shared to domain is overly broad as the company grows. We have many consultants and contractors who should not see everything in the firm. We want to switch from Shared to domain to Shared with groups to better manage least privilege. We are aware that we cannot change UI at this time.
Answer:
There's no direct way to get the inherited status of file permissions in Drive API.
Explanation:
permissionDetails is only available to shared drive items, and neither Permissions nor Files include any additional fields regarding inheritance.
Therefore, I don't think you can use inheritance to filter out the files to update.
Feature request:
There's a feature request in Issue Tracker related to this:
Sharing permission inheritance details not mention in API
You could consider starring it in order to keep track of it and to help prioritizing it, but since it hasn't had much activity, I'd strongly suggest you to file a new one using this template.
Related:
Permission details are not returned in Google Drive API V3
Google drive api v3 permission details
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?
We would like access to a client’s folder within their Google Drive and all files under that folder. This can either be a folder we create from the app or a folder the client picks.
The first approach I tried was to create the folder from the app.
The problem is that I am only able to list the folder itself, but NONE of the content. https://developers.google.com/drive/api/v3/folder
The second approach was to use the Google Picker API. There the
client can choose which folder(s) to give us access to. However we
can only get access to the folder, and none of the children
folders/files. https://developers.google.com/picker/docs
This seemed like an easy and straightforward use case. But can’t seem to find a solution in their documentation, or maybe I don’t comprehend some of the logic. A solution would be a way to either propagate the permission to all the files included in the folder it get’s picked or created… or to have the picker select all the children.
My preference is to continue with the Recommended scope https://www.googleapis.com/auth/drive.file . And it might be that the folder contains thousands of individual files multiple levels in, so it’s not a solution to manually pick the files. Any thoughts on this would be greatly appreciated, thank you!
A possible solution for your situation...
Is to create the folder in a shared drive.
Therefore, even though new files are added/updated/removed you will still be able to see all the updates and retrieve the information needed as you will have constant access to this folder.
Another solution which is more cumbersome...
Is to ask for user's permission and to re-authorize the application each time they are using it so in the case a new file is added you will have access to it.
Reference
Drive API v3 shared drives;
Drive API v3 manage shared drives.
The first approach I tried was to create the folder from the app. The problem is that I am only able to list the folder itself, but NONE of the content. https://developers.google.com/drive/api/v3/folder
The issue is probably the scope you authorized the user with. If you authorized with read only access your not going to be able to create you need full drive access to do that.
If you are using https://www.googleapis.com/auth/drive.file then you should create a folder with that and then create a file in the folder that i believe should work.
The second approach was to use the Google Picker API. There the client can choose which folder(s) to give us access to. However we can only get access to the folder, and none of the children folders/files. https://developers.google.com/picker/docs
There is no way to request access for a single folder or files. Its all or nothing really unless you use the https://www.googleapis.com/auth/drive.file scope which would only give you access to the files that your application created.
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
My expectation is that if I query the Changes Feed with a scope of drive.file, I will only receive changes to files owned by my application.
However, in testing that I have done, I am seeing files in the feed that have nothing to do with my app. At least some of them are files that have been shared with me.
Anybody know exactly how this is supposed to work?
Edit 0
Similar or duplicate StackOverflow questions
Listing files with search query returns out-of-scope results (drive.files.list call, using drive.files scope)
List ignores drive.file scope and shows shared files not created by the calling app
The files returned will not be specific to your app. Files that are "public on the web" are also reported back, regardless of whether or not your app created them or they were ever opened by the user in your app.
There is a parameter (includeSubscribed) that will filter out shared docs but this is also a bit limited (see below).
From Detect Changes:
For Google Drive apps that need to keep track of changes to files,
polling repeatedly can be both inefficient and resource-intensive. The
Changes feed provides a more efficient way to detect changes to all
files, including those that have been shared with a user. The feed
works by providing the current state of each file, if and only if the
file has changed since the given changestamp.
Here is a relevant parameter from Changes:list.
includeSubscribed boolean
Whether to include shared files and public
files the user has opened. When set to false, the list will include
owned files plus any shared or public files the user has explictly
added to a folder in Drive. (Default: true)
Scope(https://www.googleapis.com/auth/drive.file)
Meaning(Per-file access to files created or opened by the app)
The scope https://www.googleapis.com/auth/drive.file strikes this balance in a practical way. Presumably, users only open or create a file with an app that they trust, for reasons they understand.
But though, to your point, please refer to this q&a.