See: Is it possible to share a file publicly through Google Drive API
Using the information above, If I attempt to set the necessary permission for a specific file, I receive the following:
Error calling POST https://www.googleapis.com/drive/v2/files/{somefileid} permissions: (403) Insufficient permissions for this file
This error only occurs for google accounts tied to a google apps for edu setup where the admin has unchecked the option Google Apps -> Settings for Drive -> Share Settings -> Outside this organization: "Allow users to publish files on the web or make them visible to the world as public or unlisted files"
Using the Permission feed works fine otherwise, but ideally I would like to know if there is a way to check for this setting beforehand, instead of catching the 403 exception from the drive service.
You can use the About.get() endpoint to get details about the user's Drive, including this sharing setting. The field domainSharingPolicy can have the values allowed, allowedWithWarning, incomingOnly and disallowed. The first two in that list should allow publishing outside the domain, while the second two should not.
Related
When attempting to use Google federated authentication login button for a Google webapp, error message identified mismatch with related URI and javascript host domains. Solutions, as in this 2019 post (Get gmail address using Google Apps Script, Error: redirect_uri_mismatch) weren't working for me.
I then found this recent article: What is the Authorized Javascript Origin for a webapp powered by Google Script?
I understand it to say that, due to recent actions by Google, it is no longer possible to use the Google authenticator for a Google webapp because redirect URI and javascript origin host domains "cannot be googleusercontent.com”, which is the host domain for Google webapps.
So, my question duplicates earlier posts (i.e., 2019) but in new circumstances. The conclusion of the recent post I've cited seems so radical to me that I'm seeking confirmation, or explanation of how I am misunderstanding it.
As background: I need the webapp to operate under the "(me)owner" account for connectivity to owner spreadsheets, but also need the user's Gmail address (required) for application access control (no other access to user Gmail account; users not all in a shared Workspace domain). Google login would provide the user Gmail address. So, before totally abandoning this solution, I hoping to get additional clarification.
According to the official docs, it's not possible to use Google Sign-In for Websites, and this post from the Google Apps Script Issue tracker Fail to Add *.googleusercontent.com into Authorized JavaScript origins as Google Apps Script uses googleusercontent.com
To achieve your goal, as I mentioned in your previous question, you might use the UrlFeth service to call the Google Sheets API to do the connectivity to your spreadsheet and setting the web app as the user instead as you.
From https://developers.google.com/identity/protocols/oauth2/web-server#uri-validation
Domain
Host TLDs (Top Level Domains) must belong to the public suffix list.
Host domains cannot be “googleusercontent.com”.
Redirect URIs cannot contain URL shortener domains (e.g. goo.gl) unless the app owns the domain. Furthermore, if an app that owns a shortener domain chooses to redirect to that domain, that redirect URI must either contain “/google-callback/” in its path or end with “/google-callback”.
Related
How to Properly Configure GAS Web App (as another user) to Execute GAS API Executable (as me) using OAuth2?
User access request when GAS run as the user
While true that you can no longer add googleusercontent.com, you may be able to solve this by using two webapps and managing authentication/authorization between the two:
Webapp#1:
Run as: Me
Access: Anyone even anonymous
Webapp#2:
Run as: User
Access: Anyone
You may be able to create a jwt token from webapp#2 and verify it on webapp#1. As it is a custom solution, security may be questionable.
References:
Authenticate with a server - Here, webapp#1 acts as server and webapp#2 acts as client.
ScriptApp.getIdentityToken()
I am using drive api in my app and it works well , but sometimes when multiple users are logged in and I try to open a file in the browser with the link fetched via drive api I see the error message "You need permission. Want in? Ask the owner for access, or switch to an account with permission. Learn more" .
Steps to reproduce :
login to google drive with one account.
login with a second account and use drive api.
when you try to open public files you get that error.
If you add access token in url it seems to resolve the issue but thats a security risk. If you add authuser param to url that also works, but I can't find a way to get current user's authuser param.
Any help is appreciated.
I was trying to run the sample script of Google Apps Script here:
https://github.com/googlesamples/apps-script-oauth2/blob/master/samples/GoogleServiceAccount.gs
I believe I set PRIVATE_KEY, CLIENT_EMAIL and USER_EMAIL correctly from JSON file downloaded from Google Developer Console. Also I enabled Google Drive API on the project. But still I get an error in the dialog "Error: invalid_client\n no application name".
Is there any code I should add / change to run this sample script correctly?
In case you are using the correct settings (PRIVATE_KEY,CLIENT_EMAIL and a valid USER_EMAIL), the error could also be related to the permission granted to the application from the domain admin.
Since this example uses domain wide delegation of authority to impersonate the account from the USER_EMAIL, first the domain admin has to grant permissions to the application to perform this kind of operations.
To grant this permissions to the app you can do it by going to: your Admin Console -> Security -> Advanced Settings -> Manage API client access
There you will add the service account CLIENT_ID in the field "Client Name" and in the second field you will add your project scopes separated by commas. These scope should match the scopes that the application uses. In this case id Drive scope and any other you may be using.
Click the button "Authorize" and if everything goes well, then you will be able to impersonate users in your domain with that project.
Here is the related documentation. I hope this helps.
I am integrating ASP.NET application using Google Drive API. For this after authentication we re uploading Files to Google drive. I am using Google client library to Call the APIs.
Everything is working as expected I am able to authenticate user successfully and able to upload the file successfully.
In one scenario when the user Google account is suspended then I am getting refresh token from Google but my upload method is failing and it is not uploading the file to Google drive.
I want to restrict the user on Signup screen itself, when account is suspended.
What parameter do I have to pass to achieve this please suggest?
Unfortunately this info is not easily available. You have two options :
Use the Directory API to see if the user is suspended. This requires additional OAuth permissions to be provided by an admin of the domain.
At login, try and perform a Drive API call to see if you get an error or not. If you get an error (with a couple of retried) and the error message matches the one you had for suspended users, then you can deny access to the user.
Participating Components:
(all in the same project)
Android App
Web App
Service Account
The users have authorized the app on their Android devices with Cross Client Identity:
oauth2:server:client_id:[web_app_id].apps.googleusercontent.com scopes ...
Flow:
Several users request the creation of the same file through the Android app ( a file for every user is not desired, see "Known workaround" )
A service account then creates that file ( service account is owner )
Service account shares that file (by link and explicit with users)
User authorized drive service / or service account that impersonates a user tries to copy that file to the user's Google Drive ( User has to be the owner of that copy in the end)
Error:
This fails with scope drive.file ( and also drive.readonly ):
Error Message:
The authenticated user has not granted the app [project_id] write access to the file [file_id]
(btw: why write access is needed with copy()? giving users write access to the file does not change this error)
Known workaround:
It works with full drive scope
( but: my app does not need to see files it has not created - so i want to avoid it)
Same result can also be achieved by re-inserting the file instead of copying it
(this overhead is important for my app though, cause same file might be requested by multiple users)
An explicit interaction with a file from a UI Picker or so will propably not work as the file will have to be created after requesting it. also i can't think of a way how to do that without decreasing usability of the Android app.
Expected result:
www.googleapis.com/auth/drive.file: Per-file access to files created or opened by the app
It seems to me this should be enough.
As the file is created/owned/shared by my app's service account.
and copied by my app on behalf of the user.
www.googleapis.com/auth/drive.readonly Allows read-only access to file metadata and file content
At least this one should work as it should give read access to all files which should be enough to copy a "shared with user" file created by an "authorized by user" app.
Question:
the Web Application and the Service Account are in the same project.
Can the Web Application act like a Service Account on behalf of a user? if so - i don't know how. Would that make a difference anyway?
This seems like a Bug to me in this special use case, as the same result can be achieved with a workaround. At least scope drive.readonly should allow my app to copy app owned files to the user's drive.
Making a copy through the plain Service Account and then changing the owner of that copy to the User would be another workaround, but that fails too.
I must be missing something simple.
Please guide me.
Thank you.
I had the same problem and resolved it using the drive.metadata in combination with the drive.file scopes. Related question