Status Update
Comments
se...@google.com <se...@google.com>
se...@google.com <se...@google.com> #2
Hello,
Can you provide more information on the issue? I apologize if I am not understanding the issue.
I have tried to reproduce the issue and the web app returns {"parameter":{},"parameters":{},"queryString":"","contentLength":-1,"contextPath":""}
and from the URLFetchApp
the result is the html of the sing in page.
Are you referring to the return of the URLFetchApp
being the page not signed in?
Thank you!
be...@ex.mavenwave.com <be...@ex.mavenwave.com> #3
I recorded a walkthrough of the issue. It's processing and as soon as it's ready I'll share a link here.
be...@ex.mavenwave.com <be...@ex.mavenwave.com> #5
co...@google.com <co...@google.com>
co...@google.com <co...@google.com> #6
Hi,
Currently, it is not possible to programatically authorize a Google Script to read data from a WebApp.
What is the task that you are trying to accomplish? Perhaps there is no need to use a WebApp as an endpoint, and another Google resource can do this function.
Thanks!
be...@ex.mavenwave.com <be...@ex.mavenwave.com> #7
The use case mentioned in the original post is as follows:
* Desire to set up a connector that allows Workspace users the ability to query Salesforce relying on the developer authenticating with SFDC. Many users are only consumers of SFDC data and therefore do not use it directly or have a license for it.
* The Web App was configured to allow the developer to establish a connection via Oauth between Sheets/Apps Script and Salesforce.
* Once the developer authenticated, all end users could access this connection via the Web App. Deploying as a Web App maintained the 'execute as' required for authentication. The available to 'those within the Domain' ensured it was not accessible to outside users.
* End users simply had to submit a query to the Web App endpoint for it to return the results.
This worked fine until ~ April 15, at which point URLFetch seems to have stopped including the user's credentials which is required to meet the 'available to' feature.
Taking a step back, I recreated this issue with my Gmail account too. URLFetch is not working correctly when you try to access a Web App and the available to is set as 'anyone with a Google Account'. This test is simply displaying a passed parameter, nothing more. I can provide more details on these test separate from the public issue tracker as they are tied to my personal account.
co...@google.com <co...@google.com> #8
Hi,
When trying to access a Web App that is set as 'as anyone with a Google Account', an authorization is required. Previously, said authorization could be provided via Apps Script with a header. Currently, now this is not possible. Therefore, the only way to use a WebApp to function similarly to an API endpoint (as you were doing) is by making it public.
However, depending on the task that you are trying to accomplish, there might be better solutions that do not require a WebApp.
Thanks!
be...@ex.mavenwave.com <be...@ex.mavenwave.com> #9
So you're confirming that there was a change in the past ~two weeks that removed the ability to send authorization? I didn't see anything posted in a release log or other forum. Are you able to share more about the change?
co...@google.com <co...@google.com> #10
Yes,
It is now not possible to use WebApp as an endpoint. Unfortunately, there is no documentation.
Thanks!
be...@ex.mavenwave.com <be...@ex.mavenwave.com> #11
co...@google.com <co...@google.com> #12
Hi,
Yes, this functionality does no longer work. I will be closing this case as this feature is currently working as it is intended. Please do not hesitate to open a Feature Request if you wish this feature (or one similar to it) to be implemented.
Thanks!
ja...@checksheet.app <ja...@checksheet.app> #13
I'd just like to note that you constantly making breaking changes to this platform with no warning is so frustrating. At the bare minimum these should at least be announced, ideally with enough time for people to update their apps first.
[Deleted User] <[Deleted User]> #14
be...@ex.mavenwave.com <be...@ex.mavenwave.com> #15
za...@gmail.com <za...@gmail.com> #16
be...@ex.mavenwave.com <be...@ex.mavenwave.com> #17
[Deleted User] <[Deleted User]> #18
ph...@herriger-buero.de <ph...@herriger-buero.de> #19
So how does google want its users to programmatically send http requests to a web script apps that needs authorization? How is it meant to work? Any help would be very much appreciated.
be...@ex.mavenwave.com <be...@ex.mavenwave.com> #20
The answer to how to accomplish similar functionality will depend on what you are trying to do. In my case, I was using it to pass credentials for an API call to Salesforce. I ended up moving my code to a library which can be added to end-user scripts. Since you are a Google Workspace user, I suggest using Oauth2 for anything Google service related since you know the identify of the signed in user (or can determine one to impersonate). If you are creating a web app for other uses, Apps Script is not likely the best approach. You can look into AppSheet or a range of services within Google Cloud Platform.
Description
*****
I have several scripts that have been in place for years that enabled us to automate queries of systems like Salesforce and use that data in Workspace (i.e .Google Sheets). In this case, the key components are:
1) Apps Script script created web app (including doGet(e) function, deployed as a web app, run as me, available to anyone in the Workspace domain)
2) Apps Script script calling the web app via URLFetchApp.fetch (this call passes in the query that the web app uses to pass to the other system)
Note, I have already performed troubleshooting to ensure there is no issue with OAuth and my ability to query Salesforce. A test query using the service returns expected data. In addition, I've created a test script that calls a test web app with a simple doGet() function, and even that is failing.
What I've narrowed it down to is it appears that URLFetchApp is not passing along the credentials of the user executing the script. When I paste the web app URL (including added parameters), the web app functions and displays the expected output.
*****
A small code sample that reliably reproduces the issue. The sample should run as-is or with minimal setup, without external dependencies.
*****
Function deployed as web app (deployment type = web app; execute as=me; who has access=anyone within my domain)
function doGet(e) {
var params = JSON.stringify(e);
return HtmlService.createHtmlOutput(params);
}
Function calling web app
function testWebApp() {
var options =
{
"method" : "GET",
"followRedirects" : true,
"muteHttpExceptions": true
};
var url = "
var response = UrlFetchApp.fetch(url, options);
Logger.log(response.getContentText());
}
*****
What steps will reproduce the problem?
1.*****Create script for web app
2.*****Deploy web app (deployment type = web app; execute as=me; who has access=anyone within my domain)
3.*****Create script to call web app
4.*****Run web app via broswer (should get success)
5.*****Run web app via URLFetchApp (should get failure)
What is the expected output? What do you see instead? If you see error messages, please provide them.
*****
Expected:
In the test script I include, the web app should simple parse and log/display the parameters sent to the web app
What is returned on failure:
In my testing, the return of URLFetchApp.fetch is the Google Sign In page. This is after the executing user 'allows' the access external services prompt and with no additional authentication required for the web app
*****
Please provide any additional information below.
*****
The scripts that have been running using this configuration have been in place for years without issue. The last successful run looks like it was on March 30, 2022.