Question:
Is it possible to access the appProperties field in a Google Drive document via an unauthenticated user (i.e., via API Key or other method rather than Oauth)?
Background:
I have an app that works as a live document editor. It authenticates users via OAuth and allows them to save those documents to their google drive, and later re-open them in my app (google file ids are saved in my database and will load the document text into my app). Create()-ing and Get()-ing these files works fine as long as the user is signed in, and I have the "appProperties" field storing a couple of additional key metadata items.
As a next step, I would like to allow users to mark a document as "public view", and provide read-only access to their file, even for non-logged-in users. In my head, the flow would work as follows:
User_A authenticates with OAuth and creates a document, saved to their google drive.
User_A presses a button in my app, which sets the google document to a public sharing mode?
App generates a "viewer" link that User_A can share with his friends.
User_B does not have a Google account, but visits the "viewer link", and my app looks up the appropriate google document (using API key? since User_B is not logged in)
Document is loaded into my app for viewing.
This seems to mostly work; I can read the file metadata just fine using the API key, and even get the file contents. Side Note: Why do we need the API Key at all, given the quote on the google drive api page: "Note: Authorization optional."
However, the "appProperties" field always returns empty when using the API key!
Edit: After further searching I am just more confused. The closest answer I could find was from this related question here on stackoverflow:
It's very simple. appPropperties is a private field and is available only to the application that added it.
Based on this, it seems Google Drive is treating requests from my app API Key and requests from OAuth users on my app as two separate apps?
Further, I would eventually like to allow users to collaborate on a single document, owned by one user. So instead of just providing a read-only "view" link, they could generate an "editor invitation" link that would allow an authenticated user (User_B gets a google account now) to be added as an authorized collaborator (but not simultaneous editing) on the original (User_A's) document. Is that even possible?
Note I am using the Node.js google api.
This might be a bug:
appProperties are app-specific properties attached to a file. Any call from this app should be able to access them. Therefore, I think calls from this app using an API key should be able to retrieve these properties.
I could reproduce this behaviour: appProperties are populated when using OAuth, but not when using an API key, even though both are created from the same GCP project.
I filed a bug:
After researching this issue, I think this might be a bug. Therefore, I decided to file a bug on Issue Tracker:
appProperties are not populated when accessing a public File using an API key
To anyone affected by this, I'd suggest to click the top-left star in order to keep track of this and to help prioritizing it.
Reference:
Add custom file properties
Related
I wrote a code in Google Appscript to index all files in GDrive and try to identify if those files are labelled or not.
For summary, the Labels feature only available in GWorkspace business account and only the admin of the entreprise who have edit access of this feature.
I tried to use seacrhFiles(param) however the "Labels" isn't recognized by q string query Google, do we have another method to do it ?
Thank you,
Features that are part of workspace business accounts. Are not part of the public Google drive api.
You can tell by looking at the file resource object. It does not contain a field called label.
Your not going to find a method in the google drive api that will return a label on a file.
Even a Google Document resource object doesn't have it.
There may be a restricted api just for workspace users you would have to ask. But its not something i have heard of.
There will be a labels API that will allow you to to create, edit, apply, and remove labels programmatically
As of now, this API is still in development (beta stage), but you can get access to it if you contact drive-labels-feedback#google.com.
References:
https://support.google.com/a/answer/9292382?hl=en&fl=1#zippy=%2Cis-it-possible-to-apply-labels-through-an-api
https://issuetracker.google.com/167701931
Last month I got an email from The Google Drive Team.
It's about the Drive API change on September 13, 2021, and I have a question about it.
No matter how much I read, I don't understand what this update is about. Can someone explain in detail?
The Drive API I use now is set to use the save/load function among the settings for Play Game Service in the Google Play Console.
Do I have to respond to this update?
Below is the content of the email received:
Please update your code as detailed below before September 13, 2021, to avoid failing requests.
What do I need to know?
Items that have a Drive API permission with type=domain or type=anyone, where withLink=true (v2) or allowFileDiscovery=false (v3), will be affected by this security update.
In addition to the item ID, your application may now also need a resource key to access these items. Without a resource key, requests for these items may result in a 404 Not Found error (See below for details). Note that access to items that are directly shared with the user or group are not affected.
Will this change affect me?
If your application uses the Drive API to access files which have been shared with a user through link sharing, your application may be affected by this change.
What do I need to do?
To avoid errors accessing files, you must update your code for accessing files to include the appropriate resource keys. Details on how to do this for each of the affected Drive APIs is included below:
Changes to the Drive API
The resource key of an item is returned on the resourceKey field of the file metadata in the Drive API response.
If the file is a shortcut file, then the resource key for the target of the shortcut can be read from the shortcutDetails.targetResourceKey field of the same resource.
URL type fields such as exportLinks, webContentLink, and webViewLink will include the resourceKey.
Requests to the Drive API can specify one or more resource keys with the X-Goog-Drive-Resource-Keys HTTP request header.
Learn more about this change from the Drive API guide.
Changes to Apps Script
The DriveApp from Apps Script has been updated to return the resource key of a file or folder with the getResourceKey method.
Note: When fetching a file or folder, the resource key can be specified on the getFileByIdAndResourceKey or getFolderByIdAndResourceKey methods.
Changes to Drive UI Integrations
If your application is integrated with the Drive UI to create or open items, it will receive resource keys when your application is invoked from the Drive UI.
The state information for a New URL will contain folderResourceKey, which is the resource key of the folder where the new item should be created.
The state for an Open URL will contain a mapping of file ID to resource key in the resourceKeys field.
Learn more about integrating with the Drive UI on our website.
In my opinion, this email was worded very badly as it sounds like Google is telling you that if you don't change your code, things will break. The fact of the matter is Google doesn't know that, only you do.
What is the update
Google Drive is releasing a security update that will apply to some Drive files. The security update will make Google Drive files more secure by updating their links to include a resource key and may lead to some new file access requests.
Find your impacted files
On your computer, go to drive.google.com.
At the top, type: is:security_update_applied or is:security_update_removed in the search bar.
How you may be impacted
Once the security update is applied to a file, a resource key included in the URL will be required to access the file. Users who previously accessed or viewed the file won’t need the resource key in the URL. Only people who haven’t previously accessed the file will need the resource key to gain access. If they don’t have the URL with the resource key, they’ll need to request access to the file.
So if you share the file with someone New then they need to resource key, users who had been grated access previously should be fine.
Will I know if someone can’t access a file I own because they don’t have a link with the resource key?
If someone requests access to one of your files with the security update, you’ll receive an email telling you whether they tried to access your file using an old link. You can then send the person a new link with the resource key so that they can gain access.
So if you do nothing and leave your application as is then, when you try to share a file with someone, you will get an email telling you that there is a problem.
Security update for Google Drive
I have the Google Picker API implemented in an application, with the Google Drive view included. Currently, entering a search query in the search bar of the Google Drive view starts showing a drop-down with some file results included, like this:
search bar drop down
However, clicking the "magnifying glass" search button, or pressing enter, or clicking "search for all items containing...", all results in an empty picker, like this:
empty picker with no search results
I believe this is occurring because a call to https://docs.google.com/picker/pvr is returning this error as a response every time: &&&START&&&{"error":true,"errorMessage":"Internal error"}.
The parameters being sent to that /pvr endpoint are here:
start: 0
numResults: 50
sort: 3
desc: true
q: testing
cursor:
mine: 2
service: docs
type: NOT_COLLECTION
options: {"ff":true,"filterTeamDriveResults":true}
token: J********
version: 4
app: 2
clientUser: 1************
developerKey: A*************
subapp: 5
What I found is that manually removing the "filterTeamDriveResults":true key from the "options" hash and doing an ajax post directly resulted in a successful request, but for whatever reason that option is included with every request from the picker, and any time a request is made with that option included, it seems to fail with the same "Internal error" response. I'm wondering what the source of that option is, and if there's any way to remove it from our picker. As far as I can tell it doesn't seem to be controlled by any of the options in the JavaScript API that we're loading from https://apis.google.com/js/api.js?onload=onApiLoad.
This started happening to us last week as well after having been using the Google Picker API for years without any issues. Your clue about the filterTeamDriveResults key reminded me of something I had just read, about upcoming changes to the Google Drive API and Google Picker API:
Next, we’re introducing a new Drive API resource collection, called “Drives,” to replace the “Team Drives” resource collection. This new resource collection can help you create, delete, get, list and update your shared drives, and features all the same fields, resources and available methods as the “Team Drives” resource collection. If you have been using the “Team Drives” resource collection in your applications, consider migrating as soon as possible as all related fields for Drive API , Drive Activity API and Google Picker API, will no longer be supported starting June 1, 2020.
It doesn't seem related, at least not directly, but made me think that perhaps, the SUPPORT_DRIVES feature that I had seen here in the docs, could "disable" that other teamDrive feature (even though it's not really that, but still...). And indeed, that fixed it. Basically just:
new google.picker.PickerBuilder().
setAppId(appId).
addView(new google.picker.DocsView().setIncludeFolders(true)).
enableFeature(google.picker.Feature.SUPPORT_DRIVES)
...
One thing to notice is this warning when enabling this feature:
Before enabling this make sure to refer to Google Drive API documentation for enabling shared drives and make any necessary Drive Rest API changes.
Might be relevant in your case.
I am using Google Drive SDK for .NET. Everything is working as expected, except that whenever I get the permission feed for a particular document. I get the Id, kind, name, role, selflink and type fields on permission.
There is no mention of the email address of the user which is stopping me from recognizing by reading the permissions, whether a file has been shared inside the domain or outside of the domain.
I can't use Google Docs API to get the ACL on doc because I am writing an app for users over 200000 users and I will need speed which is provided by Google API Console.
What should I do?
Thanks
You can use the Documents List API to get the email addresses. I'm curious why you believe Drive is faster than Documents List, for most API calls they have a comparable response time.
https://developers.google.com/google-apps/documents-list/#retrieving_the_acl_for_a_document_file_or_collection
Thanks for the idea but can I use Document List API with the Service Accounts provided through API Console?
Why do I believe that Google Drive SDK is better? Because we don't have any control over Document List API where we can set QPS (Query per second) limits or not that I know of.
Secondly, with Document List API when you make request to servers, in the past I had to create a fault tollerent algorithm in such a way that if one request fails second should go after 2 seconds if that fails then make your next request after 5 seconds until 7 second delay.
So, I don't think that Document List API would be a good fit for processing documents over 200000 users everyday unless Google has changed the way their API used to behave?
We have a google corporate account and need to transfer ALL of a user's google drive files to another account in certain instances. We want to do what is described at the following link for "all files" but programatically via the latest Drive API http://support.google.com/a/bin/answer.py?hl=en&answer=1247799
We are currently using the following API version(s) below, coupled with domain wide authority delegation as described at https://developers.google.com/drive/delegation and are able to see a user's files, iterate over them etc.
google-api-services-drive 1.14.2-beta
google-api-client 1.14.1-beta
My question is this: it appears that the only way to change permissions is by fileId by fileId etc. Instead of having to traverse and iterate over an entire set of user's files, if we just want to transfer ALL of a user's files to another particular user: is there a way in the API to do this (ownership transfer for ALL files) rather than individual requests file/by file?
Also when transferring ownershisp, must the transferee be in the same #domain or can it be another #domain we manage? I read somewhere that you can only transfer to owners in the same domain. Does this still hold true? For instance we manage #myCompany.com and have our corporate account registered under that, however that shell account has several sub-domains within it. We would like to transfer files from users in the sub-domains to a central user in the #myCompany domain.
You need to change permissions file by file, there is no updateAll type of functionality at the moment.
You cant transfer the ownership to another domain's user. Ownership can only be transferred to another user in the same domain as the current owner.
This answer doesn't directly answer your question, but it could be helpful for both you and future visitors.
As of now, you can mass transfer files to new users with Google's new Admin console. It doesn't let you filter for specific folders, but it does allow you to transfer all of one user's Drive files to a second user.
I know you were trying to create something which uses the API to iterate through folders and files, and you probably have a very specific use-case in mind. However, in the case where you have employees leaving, or you need to transfer everything, using the following method is fast and simple.
Open the Google Admin console
Go to Google Apps > Drive
Click on "Transfer ownership"
Fill out both user fields and submit
This process will even email both users once the process is completed.
You can do this with a single call to the Data Transfer API
Exactly what is needed but only with API!
Open the Google Admin console
Go to Google Apps > Drive
Click on "Transfer ownership"
Fill out both user fields and submit
This process will even email both users once the process is completed.
If this is not possible via API calls, then there is no point deleting a user using API.