Is it possible to retrieve (or change) google drive's sharing settings using the API?
I don't want to share a file, but to see the organization's settings, as described here:
https://support.google.com/a/answer/60781?hl=en
If so, what are the required scopes that I need?
Thanks
The google Drive API is a file system API, it gives you access to files.
It does not give you access to change the settings for the Google Drive web application.
You could go in with the drive api and chance the permissions on directories and files in drive and maybe control some things that way.
Sorry, but it's not possible to do it programmatically As the Directory API: Limits and Quotas in Api Limits and Quotas states:
Groups, settings:
Groups access settings, sharing options, monitoring,
and discussion archive is managed using the Admin console. For more
information about groups settings, see the administration help
center.
Related
I developed a desktop application that saves projects locally to disk. Each project is a directory that consists out of many files. If certain files are missing the project is corrupt.
I want to add Google Drive support to my desktop application, so the user can load and save projects directly to the cloud. For clarification, the desktop application talks directly to the users Google Drive. There is no 3rd-party webservice involved.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
My question is, can I create a Google Drive App that shows up in the market place, that my desktop application can use to access the files on the users drive? Or is the market place meant to be only for 3rd party web-services that can access someones account?
TLDR; I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
First off an API key is only used to access public data. You will need to have your user authorize your application access their google drive account using Oauth2.
You will need to create a project on google cloud console and create Oauth2 credentials which will allow your application to request access of the user.
I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
Its not exactly one click but a user will have to be signed in to their google account and then click the authorize button.
I am writing a server side python script with Pydrive which needs to store a file in a specific gdrive. Pydrive and this post suggest to use a service account.
However this would mean that with the credentials of this service account all gdrives are accessible and I would rather avoid that.
Ideal only one specific gdrive or all gdrives where one specific user has access to should be accessible.
Is it possible to give programmatically access to only one specific gdrive?
[Edit]
As mentioned in the comments I am apparently not looking for a OAuth flow.
I am looking for a server-to-server communication for accessing one specific google drive using the principle of least privilege access. Doing this with a service account + domain wide delegate and google drive r/w scope would mean that with this service account all google drives can be accessed which is not what I want.
Unfortunately there is a domain wide policy in place which forbids to share google drives to "other" domains. This means I can not use a service account without domain wide delegation and just share the drive with it.
I don't understand what you mean by "programmatically", when you already tag the question as oAuth - asking for oAuth2 flow, which is interactive. When there is nobody, who would press the buttons, this probably isn't the authentication flow you're looking for. Just share a directory with a service-account; no domain-wide delegation is required (with that enabled, there would be no need to share it).
One could even abstract the whole Drive API access credentials away by using a simple Cloud Function, which has to task to update one file; triggered through HTTP, utilizing the Drive API.
Possible approach - dummy account
You could designate a new account that will be your "service account". In reality it won't be an actual service account, it will just be a dummy account that you can call something like "gdrivebot#yourdomain.com". Then you can share only what is absolutely necessary with it. I think this would be the only way to get that level of fine-grained control that you are looking for. This would require your admin to designate a new account just for this purpose though.
I am developing an app to manage room bookings via Microsoft Graph. In the end, the app needs to read and cancel meetings that are booked into a certain room resource account.
Unfortunately, there is only the permission Calendars.ReadWrite which gives the app permissions to read and write every users calendar in the tenant, including private appointments.
I have not found any possibility to restrict the permissions or specify them more granular.
Does anyone know how to deal with this? (Or do I have to fall back again to service accounts and the old exchange web services, where I can give granular permissions to that service account?)
Thanks a lot in advance!
Application permissions imply the full the level of privileges of that scope, referenced here.
If you are scoping this specific mailboxes/calendars, you use delegated permissions with a functional account that has delegated permissions on those resources. We've had to do that before. It sucks, but that is the nature of App Permissions versus Delegate.
If you have are trying to script this, you could try the "client_secret_post" authentication method for the token acquisition mentioned here and in more detail with the OpenID Connect Spec and the OAuth 2.0 Spec.
You can now restrict the calendar/mailbox access an app will have using the New-ApplicationAccessPolicy PowerShell cmdlet. Using this you set the application up to use application permissions and then create an application access policy to limit the scope of these permissions.
There's an easy to follow guide on MS docs on how to set this up:
MS docs limit mailbox access
I'm trying to figure out if it's possible to programmatically gain full or restricted access to sites, i.e. share access, to my webmaster tools account?
What I'd like to do is detailed here: https://webmasters.googleblog.com/2012/03/safely-share-access-to-your-site-in.html. However I want to be able to do this with Google's API. Is this possible?
The documentation doesn't expose any endpoints for sharing access with other users.
My app is required to upload a csv and convert to Google Sheets. So we are asking this permission "https://www.googleapis.com/auth/drive" from our user. But some of our users complain we are asking too many permissions. Is there any other settings that we can use to avoid asking too much?
Here are the permission list when user authorizes:
Upload, download, update, and delete files in your Google Drive
Create, access, update, and delete native Google documents in your Google Drive
Manage files and documents in your Google Drive (e.g., search, organize, and modify permissions and other metadata, such as title)
What scope or scopes does my app need?
As a general rule, choose the most restrictive scope possible, and avoid requesting scopes that your app does not actually need. Users more readily grant access to limited, clearly described scopes. Conversely, users may hesitate to grant broad access to their files unless they truly trust your app and understand why it needs the information.
The scope https://www.googleapis.com/auth/drive.file strikes this balance in a practical way. Presumably, users only open or create a file with an app that they trust, for reasons they understand.
https://www.googleapis.com/auth/drive.file Per-file access to files created or opened by the app
Requesting full drive scope for an app
Full access to all files in the user's Drive (https://www.googleapis.com/auth/drive) may be necessary for some apps. An app designed to sync files, for instance, needs this level of access to Drive. Apps with special needs related to listing or reorganizing files might need full scope.
Requesting drive-wide read-only scope for an app
Read-only access to all of a user's Drive files (https://www.googleapis.com/auth/drive.readonly) may be useful for certain apps. For instance, a photo browser might need to reorganize image files in a unique presentation order for a slideshow, or a mobile app might have to work around unique display constraints without needing to write anything. For apps that only need to read file metadata for all files in Drive, there's https://www.googleapis.com/auth/drive.metadata.readonly.
Requesting full drive scope during app development
One common and completely valid case for using full scope is iterative development. It may just be easier to avoid authorization-related constraints and use the full scope while testing your app during development. Then before you actually publish your app, you can back off to the file-level scope or whatever scope you really need for production operation.
Conculsion
That text was ripped directly from Google Drive Scopes page which I use as a rule of thumb when developing drive applications. In your case because you need to be able to upload files I would say you should consider testing a little with the https://www.googleapis.com/auth/drive.file scope, I haven't tried this one before but it sounds like it may work in your instance. Unfortunately I think that is your only other option besides full drive access.