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.
Related
Currently I am developing a Chrome-GMAIL extension which requires me to get the logged in user's first and last names. For experimentation, I have used the following goggle API (userinfo) and have successfully obtained the names I wanted:
https://www.googleapis.com/auth/userinfo.profile
However, using the userinfo APIs will cause a change in the OAuth2 scopes in my manifest. This change will in turn cause a permission-prompt to my existing users (if a domain wide delegation is not setup in place). Point being the idea of having more prompts in front of my user, or additional oauth scope is not really something I desire.
Currently our extensions use the following OAuth scopes and API :
Chrome's Identity API
Chrome's Storage API
GMAIL.modify
GMAIL.send
My question is, is it possible to get the first and last names using an API that is defined/allowed/provided for by any of the above scopes/permissions I listed? or is userinfo the only way to go?
Thank you very much.
Profile data like first name and last name is private data. You are corect that some Google apis give you access to some data that would normally require an extra scope. For email normally you would need to to request the email scope to get this back however the Gmail api does have an endpoint getprofile which will return the current users email address without you requesting the email scope.
However i am not aware of any apis that will give you access to the users first and last name without you requesting the profile or user.profile scope.
If you do decide to add the scope, I do recommend going though the people api rather then the userinfo endpoint as the data returned by the user info endpoint is not guaranteed to always return the name.
Since we can get a user's email address from the Gmail Add-on API, I'm wondering if we need to authenticate users with OAuth before they interact with our external service or whether we can rely on a stored secret to ensure that requests made with the user's email address are actually coming from a user using the Gmail add-on.
Since app scripts run on Google's servers and aren't modifiable by the user, we could just HMAC the request bodies in the requests to our external API with a secret stored in the Code.gs file. This would (maybe?) ensure that it this endpoint was actually being hit by Google and that the person making the request was the owner of the given email address.
For this approach to work though the secret in the code would actually need to stay secret, otherwise anyone could just hit that endpoint with any email address and post data on behalf of other users. So does this approach actually work, or is there another similar solution that might be feasible?
Otherwise we can just implement OAuth, but if there is a simpler approach that's secure then that would be preferable.
Let's say your external API just need an API key(a secret) to authorize users. You can definitely store it using Properties Service .
But the tricky part is that different user might have different API keys. To solve it , we could ask the user to enter the API key in the UI (can't be masked, though).
This is a very simple approach.
However, I would recommend using OAuth , as it is a more cleaner way.
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?
I know that the Google Drive SDK does not show the user email in the value field of the permission object due to privacy concerns. If we don't have that user email address, is there a way to know if a document is shared with anyone outside of the domain?
Also, wouldn't retrieving permissions using the document's owner authentication allow us to see that email address?
You cannot do that using Drive API. However, you can achieve this result using the old and deprecated Gdata DocumentList API
I currently have an application that will search document acls and report back on any external sharing. Since the deprecation of the document list api I would like to covert this application to Google Drive but since the user email address is no longer present in the Permission object returned from Drive is there any way to detect these shares?
Thanks.
Match the username you get from the Owner field to the users in your directory using the profile api https://developers.google.com/google-apps/profiles/. If the user is not in the directory, the user is external.
I suggest you to use 'domain' field in permission to define if your document is shared with an external user or not. You have to campare this field with the domain that you own.
Thanks,