I need to find out the creator of all shared drives via the API with a service account but can't find a way to extract that info. I can get a list of all shares and can then get a list of the permissions related to each share but can't get the creator.
Am I missing something or is it simply not possible?
Unlike files in Drive, content in shared Drives is owner by a group of users.
There is no such thing as the "creator" of a Shared Drive. And there is no "owner" role allowed either.
See the docs specific roles for shared Drives.
Update:
When shared drives are created the API assigns the role of "organizer" to the creator. And then subsequent users or groups can be assigned the role of organizers too. I guess technically the creator is the first organizer to be assigned to the Drive. But there is no method to return the creator in Google Drive API at the moment.
Related
Our app has the ability to upload documents from google drive to our app, or to embed google docs in our app.
Currently, we are looking at using these API scopes:
google docs: https://www.googleapis.com/auth/documents.readonly
"View your Google Docs documents"
google drive: https://www.googleapis.com/auth/drive.readonly
"See and download all your Google Drive files"
However, those scopes give us read access to ALL the user's google drive files and documents. We actually only want access to the files the user selects themselves to share with us. Is there a way to only gain access to user selected files, and not all files? I basically want our scope to be more restricted than those two, both for the user's comfort and privacy, as well as limiting our app potential liability.
I see that this is this scope:
https://www.googleapis.com/auth/drive.file
"View and manage Google Drive files and folders that you have opened or created with this app"
But I only want read access, and don't need the ability to 'manage' anything on the user's drive. I also don't see a parallel for google docs.
Any information, solutions, and/or suggestions are greatly appreciated.
I'm requesting authorization codes using the Google API and specify https://www.googleapis.com/auth/drive.file as the required scope since I'm going to store files on the users drives.
However, when I'm authenticating it says my application requests permission for two scopes, both
View and manage Google Drive files and folders that you have opened or created with this app
and
View metadata for files in your Google Drive
I can verify that I indeed have access to list all files on the drive.
Is the drive.metadata automatically included/required for the scope i'm requesting?
I wish to ask for as few permissions as possible.
Drive v3 scopes
https://www.googleapis.com/auth/drive View and manage the files in your Google Drive
https://www.googleapis.com/auth/drive.appdata View and manage its own configuration data in your Google Drive
https://www.googleapis.com/auth/drive.file View and manage Google Drive files and folders that you have opened or created with this app
https://www.googleapis.com/auth/drive.metadata View and manage metadata of files in your Google Drive
https://www.googleapis.com/auth/drive.metadata.readonly View metadata for files in your Google Drive
https://www.googleapis.com/auth/drive.photos.readonly View the photos, videos and albums in your Google Photos
https://www.googleapis.com/auth/drive.readonly View the files in your Google Drive
https://www.googleapis.com/auth/drive.scripts Modify your Google Apps Script scripts' behavior
You cant view metadata on a file you dont have access to see. Yes you need to be able to see them. Google is smart they know if you want to want to see the metadata your going to have to also need the ability to see the file in question. So yes you are going to need to be able to list it.
I have an application that needs to upload file to Google Drive via the ordinary Google Drive API. It needs to upload, but it never needs to download anything, list directories, read metadata or anything like that. It basically uses Google Drive as a drop box to store results of some computations.
Because of the principle of least authority, I would like to give this application the authorization to create new files, but not read or modify anything. Is this possible? I cannot see anything like this in this list, so I suspect the answer is no, but would like more informed comments.
By principle of least authority "user/process should have necessities/privileges". A file created by an app is owned(create/modify/delete) by app and no access to rest of resources.
If this definition fits in your scope then use
https://www.googleapis.com/auth/drive.file
"Per-file access to files created or opened by the app"
As stated in Choose Auth Scopes
Auth scopes express the permissions you request users to authorize for your app. While many Drive apps can function with just the required set of scopes, you may need to consider using other available scopes.
As far as I know, you can choose from the list of scopes available for the Drive API, combine them or mix and match if necessary. And, you can also add other scopes if your app requires access to any other Google APIs as given in Google APIs scopes.
To learn more about scopes, you can watch the video of Google engineers discussing related tips and tricks within the given documentation. I hope that helps.
Our platform is using a Google Service Account to create folders on Google Drive and share the folders with some of our end users. Think of it as a replacement for the traditional hot folders on an ftp site.
The problems may seem minor but when the end-user sees our shared folder the owner appears as the service account email address which is pretty ugly and I'm assuming not meant for end-user viewing: "178235058172-hi96h0con2ipmnli26tn17bdodb5ba4c#developer.gserviceaccount.com". It's also the sender email address when the user receives the "I've shared an item with you" email when we share the folder with them.
Is there any way to have the email address be the name of our service? or a way to change the name of the owner of the shared folder?
It is not possible to change the name of the service account. Nor is it possible to give it a name.
You could crate a dummy gmail account for the company. grant it owner. Give the service account write access to it.
However if the service account shares the folder with someone its still going to show as the service account has shared the item with them.
Only real work around I can think of would be to use Oauth2, authenticate the code once so you have a refresh token. Then use the refresh token to gain access faking a service account. Its not truly a service account and if something happens to the refresh token you are going to have to reauthentcate.
I have a query regarding accessing Skydrive folders programmatically through the Live SDK on Windows Phone.
So the scenario I have at hand is that a Windows phone app that I have built creates folders (and files) on your Skydrive. Now I want the following functionality which I haven’t been able to do so till now.
Is it possible that I can programmatically share my folder and files with View (and/or edit) permissions to my friends (as I know their user ID)?
If I am able to share such a folder can I access the content after logging in (with my live ID) from my phone. By accessing I mean download or stream content.
If in step 1, a person to whom the file is shared is provided edit permissions how can I programmatically edit such a file? The current problem I am facing in this step is that to update a shared folder the live sdk requests a wl.contacts_skydrive_update scope, but while logging in I am notified that no such scope exists.
This is the Error message I get when I try to get a shared_edit_link:
request_token_unauthorized: Microsoft.Live.LiveConnectException: The
provided access token does not have access to this resource. An access
token with one of the following scopes is required:
'wl.contacts_skydrive_update'.
Although the user does have edit permissions. Note: Such a scope doesn't exist.
There is a thread on this where it was listed as a bug in the beta. They said that now it should be fixed and you should only need this scope: 'wl.contacts_skydrive'.
here is the thread