Who owns the OCI object-storage GetObjectResponse.InputStream resource?
Do I need to explicitly close the stream? There is no information about this in the API doc.
As Char stated, the InputStream is "owned" by you, requiring you to open/close it.
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
I'm trying to make changes when making API calls to Google drive API because of the security update they will enforce on the 10th September.
In a subset of files, it seems it will be needed to pass a specific header in Google Drive's API requests with the file's resourceKey if the key exists (Name of the header: X-Goog-Drive-Resource-Keys). Info can be found here.
In the docs it is pointed that resource key of a file can be fetched with Google Drive's GET file method.
However from the article is unclear, that if it needs to be the admin of thee file to get that file, store the resource key and all calls afterwards made to that file from another person's perspective needs the resource key, including calling the get file method.
Do we need to pass the resource key to the get file method in Google drive API or can we can fetch the ResourceKey with a user that already had permissions to the file before this security update and use the resource key to all other calls afterwards?
From the link:
A file that is shared with the link can only be discovered by users that can access the file as a result of a type=user or type=group permission. Requests from users that only have access to these link-shared files via a type=domain or type=anyone permission, may require a resource key.
As long as you have the proper (user/group) permissions during the request, you will be able to access it without resource key. You only need it when the user only have the domain/anyone permission. And I think that it will still be needed in the get method if you don't have the proper permissions.
As for the storing the resource key and using it in future requests, that I am not sure as like you said, it wasn't provided in the information. But if the resource key is static (which is likely), then you will most likely be able to reuse it in the next requests.
Additional details here
On September 13, 2021, Drive applies a security update to make file sharing more secure. As an administrator, you can choose how to apply this update.
This update changes the links used for some files. Access to impacted files won’t change for people who have already viewed them or who have direct access, but others might need to request access.
Is it possible for a super admin to take ownership of a file that is currently owned by an arbitrary user? If so, which end point can do this? I've spent time digging through the API documentation and I'm not coming up with a clear answer. Everything I've found is related to the 1st version of the API.
https://developers.google.com/drive/v2/reference/
yes its possible.
look at how to use oauth2 for "delegation of authority". https://developers.google.com/identity/protocols/OAuth2ServiceAccount#delegatingauthority
read the drive api docs on how to use delegation on their api.
look at the drive api that changes ownership. https://developers.google.com/drive/v2/reference/permissions/update
the key part is calling that api using the service account that is impersonating that user.
beware of rate quotas using this method. if you have many files to change, you need to take care the rate is not too fast (say one per second).
Yes, the current owner can transfer ownership of a file to another user.
https://developers.google.com/drive/v2/reference/permissions/update
transferOwnership boolean Whether changing a role to 'owner'
downgrades the current owners to writers. Does nothing if the
specified role is not 'owner'. (Default: false)
Looking at:
https://developers.google.com/drive/v2/reference/permissions#resource
the values attribute which contains the email address value for the ACL is not returned by the API. It's not clear why the value isn't returned, I assume it's a privacy issue but it means Drive SDK can't support document migration (from one Google account to another) use cases where the old Documents List API v3 can:
https://developers.google.com/google-apps/documents-list/#retrieving_the_acl_for_a_document_file_or_collection
for now I'm looking at adding both Drive API and Docs v3 API scopes for my project and just using the Docs API call to retrieve the ACLs but ideally I'd be able to use just Drive API calls. Am I missing anything? Could a special scope be added to Drive API that allows ACL email address retrieval or is there some other way to handle this?
Jay
Thanks for your question Jay and thanks your answer Ali Afshar!
Unfortunately I do not understand how Google believes the following scenario should work without the email address of the users:
In Documents List API v3 you could copy a file A to file B, retrieve the ACL-information of file A (including the users email adresses) and simply add them as ACL to file B.
With Drive API you can retrieve almost the same Permission information, but without the user email address, which is still required to re-share file B to the same users.
As a sidenote: If you use GAS DefaultService DocsList, you can still receive the editor/viewers with getEditors() or getViewers(). If you manually share a file you can see all email addresses as well.
So if you ask me, the privacy issue is a valuable argument, but it does simply not apply here.
Jan
Since this question was posted, Drive API has been updated to allow permissionId to be sent on permissions.insert() (the id attribute). This allows for migration of ACLs without ever needing to know the email addresses (just straight copy the permissionIds over to the new file).
Additionally:
the permissions.getIdForEmail() API call provides a quick way to get the ID for a given email address
when returning permissions for a file with permissions.get() or permissions.insert(), the domain attribute is included which should help determine if the ACL raises security concerns.
I believe these features cover most use cases where the actual ACL email address retrieval was needed.
You are absolutely correct, the email address is hidden for privacy. It is not right that a user should see the email addresses of all other users that have access to the file. But I'm not sure I quite get the problem. Are you migrating using service accounts, or are users individually authorizing the migration?
The value in the permissions feed is consistent for each user, and that value is available in the about feed for a user. I assume you know the email address of the users, so you can authorize for each of them With a service account, and you can migrate the data.
You should not need the Drive API scope and the Docs v3 API scope, they are pretty much the same scope.
Also resurrecting this old thread, I had the same issue while migrating documents.
A workaround:
- Create a temporary folder
- Insert a permission for the user
- retrieve the id from the permission
Not nice, but works for me.
How does one use oauth in a FLOSS app where we can't keep a secret key? If other see the secret and the key, can't he use it to use the user account as if he where me?
I have dealt with the issue in my own open source Twitter apps.
You do NOT distribute the ConsumerKey or ConsumerKeySecret with your source code. A reasonable approach is to create two constants/global variables (or whatever) that hold these values, and these are EMPTY in the source that you publish. Include some documentation that explains to other developers how to acquire their own keys and how to modify the source to install them.
If you are distributing compiled binaries, you would compile with the ConsumerKey and ConsumerKeySecret values populated so the application runs.
There is no -perfectly secure- way to handle this; it's the nature of OAuth. You can, however, be -reasonably- secure, and that's what this approach achieves.