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.
Related
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.
My chrome app needs to save a file with human-readable or standard format such as SQLite (It should be readable outside Chrome).
Is there any API suitable for this purpose?
Some files with .localstorage extension (SQLite format) are in Chrome\User Data\Default\Local Storage folder. Is it possible to create such files by the app?
Edited: The app should not ask user for extra permission.
Thanks for your consideration.
chrome.fileSystem API is what you need.
You will need to ask the user at least once where to save the file, but then you can retain the entry to write again to the same file/folder.
There is no way around asking the user to "escape the sandbox".
You'll want to use the Quota Management API. This is per-origin storage, and you request specific amounts of quota.
It sounds like you also want your users to open the files directly? There's an HTML5 filesystem explorer Chrome app that you can use. It'll show you the files, and you can figure things out from their URLs (e.g. I'm currently using filesystem:http://localhost:8000/temporary/bar for a local experiment).
Or are you looking for something more user friendly? I think you have to use file save in that case, the same way Google Drive does.
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.
The sample app in the docs loads a file into a document and then very nicely keeps the document synchronized across all instances of the app. Awesome!
I don't understand when a user is allowed access to the realtime document. The load / save to the drive file is clearly regulated by permissions, but it seems that if I have the key to a realtime document I can make whatever changes I like to that document. Another user, who is allowed to save to the drive file, can get evil updates to the realtime doc and might naively save them to the backing file.
I've tested this briefly by removing access to a file and verifying that the blocked user can indeed still change the realtime document even after access to the drive file is blocked.
Does anyone know a way to block updates to the realtime document from someone that doesn't have access to the relatively-offline file?
Additionally, I'd like to give each collaborator private space in the document that other collaborators cannot affect. Does anyone know of plans for per-key permissions like Firebase supports?
Access to a Realtime file is restricted with sharing and permissions rights exactly the same way as regular Drive files. No user can modify it if they do not have access.
You can achieve the private collaborators part by having a separate private file. If this is not what you require, please give additional details.
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.