Does anyone here know if you on Google Drive somehow can track if a public shared link to a file have been used?
That is, the resource have been downloaded, viewed or otherwise "touched"?
Yes, and no
No: For consumer accounts.
Yes: For within a domain for Google Apps unlimited account, you can using the Admin API to receive view events.
Find the documentation here: enter link description here, relevant except follows.
Retrieve Google Drive events by event name
To retrieve a report of all instances of specific event type such as creating or editing a document, use the following GET HTTP request using the authorization token described in the authorization documentation. The userKey is the primary email address of the user in the report. The eventName can either be a access or acl_change event. For the eventName information, see the Drive event names reference information. For more information about the request's query strings and the response properties, see the API Reference. For readability, the following example is formatted with line returns:
GET https://www.googleapis.com/admin/reports/v1/activity/users/all
/applications/drive?endTime=a date&startTime=a date
&filters=event name parameter relational operator parameter value,...
&actorIpAddress=user's IP address
&maxResults=maximum number of events returned on a response page
&eventName=either a view or edit event
Related
I've managed to get the Google Drive API to run against a Google doc in my personal drive (of a Corporate paid account) using their example (after correcting for Python 2 syntax).
However, it shows only edit and comment as primary actions in that history, I don't see any actions saying just view.
Does that mean that there is no action recorded for document views? or that they are simply recorded as comment or something else, since the document URL always seems to redirect to .../edit even if I only grant View privileges.
There is no view action detail in Drive Activity API.
edit or comment action detail cannot be used to get view action history.
I tried to view a document and get all its activity and there is no new record seen (either view, edit or comment).
If you want to get the view history of a document, here are some of your options:
Use Drive API Files:get(), it will return a file resource which contains viewedByMe flag and viewedByMeTime datetime parameter.
It will only show the last time you viewed the file. If the file is shared, you cannot use this to get the recent datetime the file was viewed by other user.
If you have an admin account, you can use activities.list in Admin SDK Reports API to access Drive audit logs which contains view log activities and other events. See Drive Audit Activity Events for a list of events available.
Sample activities.list Request Parameters:
userKey: all
applicationName: drive
eventName: view
filters: doc_id==13NgKy87BggedOXnmkymygTyEh0xxxxxxxx
NOTE:
If the file was viewed by a user outside your organization, the email address will not be available (User is anonymous)
Drive audit logs has a data retention time of 6 months. You can access Drive audit logs data this far back.
References:
View user Google Drive file activity
Data retention and lag times
I'm developing a script that checks every link (URL) in a Presentations to meet the following criteria:
If the link follows to a document within the same domain of the Presentation that I'm currently editing then remove the link.
The question is, is there a property, or any method in GAPPS that allows me to check that information, because I've reviewed the whole API and I cannot find anything like that.
There is no direct way to get the domain that a file belongs to buy you might be able to get the Presentation owner by using getOwner ( a method of the Class File from the Drive Service) or the equivalent of the Drive Advanced Service.
Once you get the owner email address, then you could extract the domain by using JavaScript's global object methods like String.prototype.split, regular expressions, etc.
Related
Determine the owner of a Google Drive document with a service account
returning document owner for large list of Google Drive doc IDs
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.
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
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.