In my app, I have requested users' permissions for their google sheets. However, there are 2 showing up. I don't think I need 1. because 2. is good enough. How can I turn it off or change to access only the spreadsheets opened or created with this app?
1. View and manage your spreadsheets in Google Drive
2. View and manage Google Drive files and folders that you have opened or created with this app
As per your comment, you are utilizing these two Services:
Spreadsheet Service
Requires authorization to access and manage sheets in drive. Even a single spreadsheet, regardless of the owner, requires this authorization.
Drive Service
Requires authorization to access and manage drive files. But this does not grant permissions to modify these files through other services such as the Spreadsheet Service .
Each of these require a different authorization set. Which is why you see two different requested permissions. This does not mean that the app now has access to every sheet on that users drive, it still only has access to the sheets that are appropriately shared with the user the script is executing as. See this answer as well, which is marginally related.
If you want to remove app-permission 1 from showing, you may manage users and limit app-specific permissions by using the "Role" drop-down to select a predefined role for a user or check individual boxes to turn on permission that apply to all apps in your account. Here's how:
Sign in to your Google Play Developer Console.
Click Settings.
On the left menu, click User accounts & rights.
Near the right side of a row, click the Settings Gear icon.
Select Add app specific rights.
Click the search box to find or select an app.
You can select multiple apps to add permissions for multiple apps at once.
Check boxes to add permissions.
Click Add rights.
To remove app-specific rights, click the X next to a permission on the User accounts & rights page.
Developer Console Help - Add developer account users & manage permissions might help.
Related
I installed the official app Google Cloud to manage and monitor my Google Cloud ressources. I then logged in using an account with an Owner role on the top structure My Organization and an Owner role on all its sub-projects as well. I am super-admin in Google Workspace.
However, I can't seem to access/list any project or ressource in the app. Basically it tells me I lack permissions.
I tried looking for specific IAM permissions for this scenario but without luck.
What am I missing?
To get the permissions that you need to manage access to a project, folder, or organization in Google official cloud you need to have following IAM roles on the resource that you want to manage access for (project, folder, or organization):
To manage access to a project: Project IAM Admin
(roles/resourcemanager.projectIamAdmin)
To manage access to a folder: Folder Admin
(roles/resourcemanager.folderAdmin)
To manage access to projects, folders, and organizations:
Organization Admin (roles/resourcemanager.organizationAdmin)
To manage access to almost all Google Cloud resources: Security Admin
(roles/iam.securityAdmin)
For more information about granting roles, see Required permissions and Manage access and check these roles.
I found the solution:
In Google Workspace Admin console, you must activate the service named Additional services without individual control.
Menu 'Apps' > 'Additional Google services' > 'CHANGE' next to 'Access to additional services without individual control for all organisational units is turned Off' (info icon in the upper zone) > 'ON for everyone'
Struggling to get a difinitive answer on this so would appreciate any help.
We have a Python Script that pulls data from a piece of hardware and uploads it to a Google Sheet using the drive / sheets api.
We also have a global policy in the top level OU to Restricts sharing outside of the organisation.
If you create a seperate OU in GAdmin console where external sharing is allowed and move the Account assosiated the with Gdrive / Gsheets to this OU, everything works. You share the sheet with the service account as part of the process.
This also means however the owner of the account can share other data using the account. We'd like to lock down the account , but I'm not sure it's possible as you can't whitelist service accounts, only other Gsuite domains.
There is also a point discussed about using the option to grant the service account "delegating domain-wide authority to the service account for a particular API scope (i.e. Drive) -" but from a security point of view that option that doesn't seem optimum either.
Is there any other way to achieve the access where by you can restrict sharing only with the service account and organisation accounts.
The below describes the process:
https://towardsdatascience.com/accessing-google-spreadsheet-data-using-python-90a5bc214fd2
Similar question previously.
Whitelisting Service Account for Google Drive Document Access
When I sign in an app via Dropbox, it says:
ABC would like access to its own folder, Apps › ABC (emphasis mine)
This is to sign, that the app, ABC, can access only its folder.
However, this folder is normally visible in the Dropbox directory and synced.
Is there a way to achieve this with Google Drive? It seems like using the app-specific data feature prevents users from using the directory in any way except the app. Granting a permission to use the whole Google Drive gives the app way too much permissions. Dropbox has this feature done well. IS there a way to do a sing-up process this way with Google Drive?
When your ABC app calls Google Drive APIs on behalf of a user, you're going to be using oAuth to authorize ABC. From Drive API v3 docs:
The details of the authorization process, or flow for OAuth 2.0 vary somewhat
depending on what kind of application you're writing. The following general process
applies to all application types:
When your application needs access to user data, it asks Google for a
particular scope of access.
Google displays a consent screen to the
user, asking them to authorize your application to request some of
their data.
Google Drive's resource authorization scheme includes a number of "permissive" scopes where your app can (for example) request access to the user's entire Drive and "narrow" scopes. In the latter case your app is restricted to certain Drive files and/or folders. In late 2018 Google announced Project Strobe that promised to tighten restrictions around "permissive" scopes for many Google services, including Drive. In May 2019, they rolled an updated policy for Drive APIs:
With this updated policy, we’ll limit the types of apps that have
broad access to content or data via Drive APIs. Apps should move to a
per-file user consent model, allowing users to more precisely
determine what files an app is allowed to access. This means that only
certain types of apps can request restricted scopes from consumer
Google accounts. As always, G Suite administrators are in control of
their users’ apps.
The more user-friendly, narrower scopes are tagged and referred to as Recommended throughout Google API docs. For Drive you have 3 recommended scopes :
https://www.googleapis.com/auth/drive.appfolder Allows access to the
Application Data folder
https://www.googleapis.com/auth/drive.file Per-file access to files
created or opened by the app. File authorization is granted on a
per-user basis and is revoked when the user deauthorizes the
app.
https://www.googleapis.com/auth/drive.install Special
scope used to let users approve installation of an app, and scope
needs to be requested
Your use case could fall into either drive.appfolder or drive.file scope. drive.appfolder works well if you're looking to store app-specific data that the user won't and shouldn't touch:
The application data folder is a special hidden folder that your app
can use to store application-specific data, such as configuration
files. The application data folder is automatically created when you
attempt to create a file in it. Use this folder to store any files
that the user shouldn't directly interact with. This folder is only
accessible by your application and its contents are hidden from the
user and from other Drive apps.
The application data folder is deleted when a user uninstalls your app from their
MyDrive. Users can also delete your app's data folder manually.
drive.file is applicable if your use case has to do with some data being created by your app on behalf of the user and the user or other users should be able to see/edit/share these documents. The issue with drive.file is that it only applies to "objects" your app creates. If your ABC app creates folder Foo and then creates some files within that folder, your app will be able to access the folder and these and only these files.
With drive.file there's no parent/child ownership semantics and no propagation of permissions from parent to child. The user (in their own browser without your app) could create more files in the Foo folder but your app won't be able to read them.
It's worth noting that drive.file is not granting access to a particular folder...but it sort of amounts to an equivalent end result for a to-be-created (by your app) folder or folders.
If you're looking for a way to get access to an existing folder, you may want to look into one of the Sensitive or Restricted scopes. Using one of these scopes requires your app to go through a security review.
Most apps only have permission to store data in the Application Data folder
There is more information about API permissions at About Authorization
The drive.file scope might work for some since it appears to give access to individual files that the user OK'd. How does the user OK a file? According to the post below, they would send a file from the Drive app to my app.
So, unlike Dropbox or OneDrive, Google Drive has only 2 types of permissions: Drive or Drive.File. Simple!
I've been reading on Google Drive's API which seems straight-forward enough, but I'd like to use it a bit differently.
Instead of a client-side application, I need to be able to batch copy files in a given directory on a server to a specific Google Drive account which I have control over. To elaborate, I'm implementing a scan-to-email feature in which a user can scan a document on our copier which is then copied to that Google Drive account.
This is done for internal users, so the accounts would be generic and there would be no reasons to change the passwords. Is this possible at all?
I would recommend you go with a service account. Think of a service account as a user, a service account will have its own drive account. You will be able to upload the files to it, and your application wont be required to login as it will have the login built into it. You will not be able to login and see the files for this account via the web interface.
In order for the users to access the files again you have a few options.
You can then set the permissions on the files to allow the different users to access the files via there google drive accounts. Google drive api permissions
you could create your own interface and use files list to list the files that are currently stored on the service account.
Heads up:
You will at some point want to know how much space the service account drive has left. use about.get
Google has a number of client libs that can make doing all of this quite easy. but you haven't said what language you are planning on doing this in.
You could rely on the insert method of the "File" resource within the API. This will allow you to create a Google Drive File with the file type based on the scanned file. Refer to this document for examples and further assistance: https://developers.google.com/drive/v2/reference/files/insert#examples
https://developers.google.com/drive/web/manage-uploads
I'm writing some code which will connect to a user's Google apps email account via IMAP and make a complete archive of everything. In this process, I would like to back up the google chat history that is located in the "Chats" label. To do this however, I need to tick the "Show in IMAP" checkbox in the labels window. Is there a way to set this automatically via the Google admin api? I know I have access to read the user's labels and create my own, but I didn't see any reference to modifying existing labels or setting this value.
Unfortunately there is no way to programatically set Chats to show in IMAP. Your app should attempt to access the folder and if it's not visible via IMAP, prompt the user with instructions for manually setting the Chats label to visible via IMAP.