Moving a file into a Google Drive folder without changing its ACL - google-drive-api

In Google Drive, when puting a file into a folder, the ACLs of the folder are added to the ACLs of the file.
Is there a way to avoid that? In my use case, a lot of user have "Can View" access on the folder, but only a subset of those will ultimately allowed to view that file. Even if we quickly follow with an ACL update request, there will be a short amount of time during which the visibility of the file is too broad for my use case.
Note that a solution involving having a short period of time during which the access is more limited that what it will ultimately be would be acceptable. Also, I am ready to use either Drive API or Document List API.

This might help
I was so happy when I found it! Unfortunately, it still cannot override file settings, in the case of a document owned by someone else than the containing folder's creator.

Related

How to find out whether a GDrive (not Shared) file has inherited permissions, specifically shared to domain?

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

Google Drive API permission to children 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.

How do I avoid Google Drive API audit? -- Only Read access is needed to list files from folder and to download them

The product I'm working on currently uses the scope "https://www.googleapis.com/auth/drive" (which is now "restricted" by Google), which gives full read and write access to a user's Drive account, including app metadata. But we only need read access to list all files and folders inside a specific folder, and we need to be able to download those files, that's all.
Google Drive API will soon apply the new "restricted" scope policy (https://support.google.com/cloud/answer/9110914#restricted-scopes), which will require us to go through a very expensive audit (tens of thousands of dollars...). Is there a possible workaround to get 'read-only' access on a specific folder, and avoid the audit (note that https://www.googleapis.com/auth/drive.readonly is also a restricted mode)?
I'm aware of the "https://www.googleapis.com/auth/drive.file" scope (which is "recommended" by Google, so no audit required), which almost solves this problem. But we have thousands of users bringing in data from multiple Drive Folders, and pushing new files daily. This scope would introduce a manual step for a client each morning to have to "approve" every new file, and this would be a big scalability/usability problem.
Ideally, I would like Google to add a new scope, like a read-only access to anything inside a folder, before they go forward with their audit... but i doubt that this will happen soon.
Does anyone know of a better option?
[EDIT] For reference, here is the list of scopes and we can see which ones are "restricted", "sensitive" and "recommended" : https://developers.google.com/drive/api/v2/about-auth
Solution
Hi! So after taking a better look at this it seems that restricted scopes do NOT require any paid audit. The main difference is that they will have a wider access to user's data and thus it requires you to go through a restricted scope verification process.
You can use these restrictive scopes (the one that best fits your application) without the need of paying any audit. See more information about how to implement restrictive scopes here.

Get file list from google drive public folder shared by link via API

I'm trying to create script to download all files from another user shared folder in google drive using rest api. If i'm right, there are two variants:
Using drive.children.list, with folder ID
Using drive.files.list, with search query like 'FOLDER_ID in parents'
But both of this variants returning only files which were once opened by my google account in browser. If I open file in browser - this file will appear in results of API calls.
Folder is shared for anyone, who has link.
Where is the problem, how I can list all files in folder?
Since you did not give us any info about the SCOPE, I am wild-guessing that it may be your problem. You probably have FILE scope, instead of DRIVE.
Also, I would recommend to test these things with 'TryIt!' here. You can quickly modify both scopes and queries there.
Good Luck
This is a bug/quirk in the Drive API, though there is an easy workaround. If you call files.update with 'addParents=root' it'll add the shared folder under 'My Drive'. This has the effect of making the files part of your corpus and they'll appear in results.

Is there any way to have private data?

I'm aware of shortcut links. Looking for behavior similar to that of a native Google doc. File exists, possibly takes up storage, can be renamed/moved/deleted, but the data inside shouldn't be modified except by the app. Possibly, defining export formats/links.
I believe the answer is a simple "no" - Google Drive is for storing user files, not protected application data or configuration data. So you could put a file to a users drive, but only the owner of the drive can control whether the file is shared or changed. So they can edit it, you can't stop them, and there's no reason to think that'll ever be a feature in the future.
To have such control you will need to store such data on your own server, or some other such storage medium.
The only other thing that you would do with only Google Drive is encrypt the configuration file you store, for instance, so it couldn't be easily edited - but that's probably just a bad idea. If you must save a configuration file to a persons drive, bury it inside an application folder and sanity check it to ensure it isn't corrupt - but don't count on a person or application never opening and editing it. If it's something a person shouldn't be able to read or change, don't save it to their drive.
As of April 2012, application data is supported: What is the Application Data folder?.
"Export format links" could be done with Custom file properties, though, I'm unsure of what kind datatypes are supported for the value beyond the example string.