Authentication issue with Google Apps Script deployed as a web app
up vote
5
down vote
favorite
I am facing HTTP 401 errors while trying to call a deployed Apps Script (as a web app, accessible to "anyone") from a second GAS with UrlFetch and a bearer in authorization header. The scripts were working fine for months until around two weeks ago.
Here are two small scripts to reproduce the error.
Script A - Deployed as a web app, accessible to "Anyone".
function doGet(e) {
var params = e.parameter.params;
console.info("Parameters : " + JSON.stringify(e.parameter));
return ContentService.createTextOutput("Success");
}
Script B - Calling the script A via UrlFetch
function callURL() {
var param = {
method : "get",
headers : {"Authorization": "Bearer " + ScriptApp.getOAuthToken()},
followRedirects : true,
muteHttpExceptions:true,
};
var url = "https://script.google.com/macros/s/<script_A_deployed_url>/exec?param1=test";
var resp = UrlFetchApp.fetch(url,param);
if(resp.getContentText() != "Success"){
console.info(resp.getContentText());
throw resp.getContentText();
}
}
|
show 1 more comment
up vote
5
down vote
favorite
I am facing HTTP 401 errors while trying to call a deployed Apps Script (as a web app, accessible to "anyone") from a second GAS with UrlFetch and a bearer in authorization header. The scripts were working fine for months until around two weeks ago.
Here are two small scripts to reproduce the error.
Script A - Deployed as a web app, accessible to "Anyone".
function doGet(e) {
var params = e.parameter.params;
console.info("Parameters : " + JSON.stringify(e.parameter));
return ContentService.createTextOutput("Success");
}
Script B - Calling the script A via UrlFetch
function callURL() {
var param = {
method : "get",
headers : {"Authorization": "Bearer " + ScriptApp.getOAuthToken()},
followRedirects : true,
muteHttpExceptions:true,
};
var url = "https://script.google.com/macros/s/<script_A_deployed_url>/exec?param1=test";
var resp = UrlFetchApp.fetch(url,param);
if(resp.getContentText() != "Success"){
console.info(resp.getContentText());
throw resp.getContentText();
}
}
Did you tried doing the same using Postman/etc ?
– Mohammad Umair
Apr 25 at 12:00
Yes, I managed to reproduce this behavior using Insomnia.
– Q_C
Apr 25 at 12:04
What's the exact error message ? Earlier same setup & code was workin ?
– Mohammad Umair
Apr 25 at 12:08
401 Unauthorized. Yes, we have been using this authentication mechanism since several months without any issue.
– Q_C
Apr 25 at 12:15
Try publishing app with public access (Anyopne, even anonymous) see if that works, if that works, then make sure header is coming properly
– Mohammad Umair
Apr 25 at 13:08
|
show 1 more comment
up vote
5
down vote
favorite
up vote
5
down vote
favorite
I am facing HTTP 401 errors while trying to call a deployed Apps Script (as a web app, accessible to "anyone") from a second GAS with UrlFetch and a bearer in authorization header. The scripts were working fine for months until around two weeks ago.
Here are two small scripts to reproduce the error.
Script A - Deployed as a web app, accessible to "Anyone".
function doGet(e) {
var params = e.parameter.params;
console.info("Parameters : " + JSON.stringify(e.parameter));
return ContentService.createTextOutput("Success");
}
Script B - Calling the script A via UrlFetch
function callURL() {
var param = {
method : "get",
headers : {"Authorization": "Bearer " + ScriptApp.getOAuthToken()},
followRedirects : true,
muteHttpExceptions:true,
};
var url = "https://script.google.com/macros/s/<script_A_deployed_url>/exec?param1=test";
var resp = UrlFetchApp.fetch(url,param);
if(resp.getContentText() != "Success"){
console.info(resp.getContentText());
throw resp.getContentText();
}
}
I am facing HTTP 401 errors while trying to call a deployed Apps Script (as a web app, accessible to "anyone") from a second GAS with UrlFetch and a bearer in authorization header. The scripts were working fine for months until around two weeks ago.
Here are two small scripts to reproduce the error.
Script A - Deployed as a web app, accessible to "Anyone".
function doGet(e) {
var params = e.parameter.params;
console.info("Parameters : " + JSON.stringify(e.parameter));
return ContentService.createTextOutput("Success");
}
Script B - Calling the script A via UrlFetch
function callURL() {
var param = {
method : "get",
headers : {"Authorization": "Bearer " + ScriptApp.getOAuthToken()},
followRedirects : true,
muteHttpExceptions:true,
};
var url = "https://script.google.com/macros/s/<script_A_deployed_url>/exec?param1=test";
var resp = UrlFetchApp.fetch(url,param);
if(resp.getContentText() != "Success"){
console.info(resp.getContentText());
throw resp.getContentText();
}
}
asked Apr 25 at 11:51
Q_C
1788
1788
Did you tried doing the same using Postman/etc ?
– Mohammad Umair
Apr 25 at 12:00
Yes, I managed to reproduce this behavior using Insomnia.
– Q_C
Apr 25 at 12:04
What's the exact error message ? Earlier same setup & code was workin ?
– Mohammad Umair
Apr 25 at 12:08
401 Unauthorized. Yes, we have been using this authentication mechanism since several months without any issue.
– Q_C
Apr 25 at 12:15
Try publishing app with public access (Anyopne, even anonymous) see if that works, if that works, then make sure header is coming properly
– Mohammad Umair
Apr 25 at 13:08
|
show 1 more comment
Did you tried doing the same using Postman/etc ?
– Mohammad Umair
Apr 25 at 12:00
Yes, I managed to reproduce this behavior using Insomnia.
– Q_C
Apr 25 at 12:04
What's the exact error message ? Earlier same setup & code was workin ?
– Mohammad Umair
Apr 25 at 12:08
401 Unauthorized. Yes, we have been using this authentication mechanism since several months without any issue.
– Q_C
Apr 25 at 12:15
Try publishing app with public access (Anyopne, even anonymous) see if that works, if that works, then make sure header is coming properly
– Mohammad Umair
Apr 25 at 13:08
Did you tried doing the same using Postman/etc ?
– Mohammad Umair
Apr 25 at 12:00
Did you tried doing the same using Postman/etc ?
– Mohammad Umair
Apr 25 at 12:00
Yes, I managed to reproduce this behavior using Insomnia.
– Q_C
Apr 25 at 12:04
Yes, I managed to reproduce this behavior using Insomnia.
– Q_C
Apr 25 at 12:04
What's the exact error message ? Earlier same setup & code was workin ?
– Mohammad Umair
Apr 25 at 12:08
What's the exact error message ? Earlier same setup & code was workin ?
– Mohammad Umair
Apr 25 at 12:08
401 Unauthorized. Yes, we have been using this authentication mechanism since several months without any issue.
– Q_C
Apr 25 at 12:15
401 Unauthorized. Yes, we have been using this authentication mechanism since several months without any issue.
– Q_C
Apr 25 at 12:15
Try publishing app with public access (Anyopne, even anonymous) see if that works, if that works, then make sure header is coming properly
– Mohammad Umair
Apr 25 at 13:08
Try publishing app with public access (Anyopne, even anonymous) see if that works, if that works, then make sure header is coming properly
– Mohammad Umair
Apr 25 at 13:08
|
show 1 more comment
2 Answers
2
active
oldest
votes
up vote
2
down vote
Can you confirm the following points again?
- For the client side, are there some functions except for your script of the client side in the project? If there is only the script in the project, the scope for accessing to Web Apps is not enough. The scopes for Drive API are required to be included in the scope of access token.
- You can see the current scopes at File -> Project properties -> Scopes.
- For example, those are the following scopes.
https://www.googleapis.com/auth/drive.readonlyhttps://www.googleapis.com/auth/drive.fileshttps://www.googleapis.com/auth/drive
- In my log, when
Who has access to the app:is installed asAnyone, I confirmed that from April 11, 2018, it is required to be shared the project to access to Web Apps. This might be due to the update of Google.
- Please share the project of Web Apps with users and try again.
- For the Web Apps server side, if you set
User accessing the web appforExecute the app as:, please authorize the scopes using own browser. This authorization is required to do only one time.
If these were not useful for your situation, I'm sorry.
Thanks ! You point me in the right direction. It seems that now, script B needs the Drive scopes and at least reading rights on script A to avoid 401 errors. I will clarify this in a new answer.
– Q_C
Apr 26 at 8:52
@Q_C Welcome. Recently, I summarized about Web Apps. If this is useful for you, I'm glad. github.com/tanaikech/…
– Tanaike
Apr 26 at 11:17
Excellent work, well done !
– Q_C
Apr 27 at 11:52
add a comment |
up vote
2
down vote
accepted
Tanaike pointed me in the right direction. Apparently, some internal rules recently changed in the authentication mechanism for Apps Script deployed as a web app.
For B script, the default scope with UrlFetch is https://www.googleapis.com/auth/script.external_request, but it looks like we now need at least read access to A script, which means we also need Drive scopes.
In order to achieve that, you can for example have this function in B script to authorize them.
function setScope() {
DriveApp.getRootFolder();
}
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
Can you confirm the following points again?
- For the client side, are there some functions except for your script of the client side in the project? If there is only the script in the project, the scope for accessing to Web Apps is not enough. The scopes for Drive API are required to be included in the scope of access token.
- You can see the current scopes at File -> Project properties -> Scopes.
- For example, those are the following scopes.
https://www.googleapis.com/auth/drive.readonlyhttps://www.googleapis.com/auth/drive.fileshttps://www.googleapis.com/auth/drive
- In my log, when
Who has access to the app:is installed asAnyone, I confirmed that from April 11, 2018, it is required to be shared the project to access to Web Apps. This might be due to the update of Google.
- Please share the project of Web Apps with users and try again.
- For the Web Apps server side, if you set
User accessing the web appforExecute the app as:, please authorize the scopes using own browser. This authorization is required to do only one time.
If these were not useful for your situation, I'm sorry.
Thanks ! You point me in the right direction. It seems that now, script B needs the Drive scopes and at least reading rights on script A to avoid 401 errors. I will clarify this in a new answer.
– Q_C
Apr 26 at 8:52
@Q_C Welcome. Recently, I summarized about Web Apps. If this is useful for you, I'm glad. github.com/tanaikech/…
– Tanaike
Apr 26 at 11:17
Excellent work, well done !
– Q_C
Apr 27 at 11:52
add a comment |
up vote
2
down vote
Can you confirm the following points again?
- For the client side, are there some functions except for your script of the client side in the project? If there is only the script in the project, the scope for accessing to Web Apps is not enough. The scopes for Drive API are required to be included in the scope of access token.
- You can see the current scopes at File -> Project properties -> Scopes.
- For example, those are the following scopes.
https://www.googleapis.com/auth/drive.readonlyhttps://www.googleapis.com/auth/drive.fileshttps://www.googleapis.com/auth/drive
- In my log, when
Who has access to the app:is installed asAnyone, I confirmed that from April 11, 2018, it is required to be shared the project to access to Web Apps. This might be due to the update of Google.
- Please share the project of Web Apps with users and try again.
- For the Web Apps server side, if you set
User accessing the web appforExecute the app as:, please authorize the scopes using own browser. This authorization is required to do only one time.
If these were not useful for your situation, I'm sorry.
Thanks ! You point me in the right direction. It seems that now, script B needs the Drive scopes and at least reading rights on script A to avoid 401 errors. I will clarify this in a new answer.
– Q_C
Apr 26 at 8:52
@Q_C Welcome. Recently, I summarized about Web Apps. If this is useful for you, I'm glad. github.com/tanaikech/…
– Tanaike
Apr 26 at 11:17
Excellent work, well done !
– Q_C
Apr 27 at 11:52
add a comment |
up vote
2
down vote
up vote
2
down vote
Can you confirm the following points again?
- For the client side, are there some functions except for your script of the client side in the project? If there is only the script in the project, the scope for accessing to Web Apps is not enough. The scopes for Drive API are required to be included in the scope of access token.
- You can see the current scopes at File -> Project properties -> Scopes.
- For example, those are the following scopes.
https://www.googleapis.com/auth/drive.readonlyhttps://www.googleapis.com/auth/drive.fileshttps://www.googleapis.com/auth/drive
- In my log, when
Who has access to the app:is installed asAnyone, I confirmed that from April 11, 2018, it is required to be shared the project to access to Web Apps. This might be due to the update of Google.
- Please share the project of Web Apps with users and try again.
- For the Web Apps server side, if you set
User accessing the web appforExecute the app as:, please authorize the scopes using own browser. This authorization is required to do only one time.
If these were not useful for your situation, I'm sorry.
Can you confirm the following points again?
- For the client side, are there some functions except for your script of the client side in the project? If there is only the script in the project, the scope for accessing to Web Apps is not enough. The scopes for Drive API are required to be included in the scope of access token.
- You can see the current scopes at File -> Project properties -> Scopes.
- For example, those are the following scopes.
https://www.googleapis.com/auth/drive.readonlyhttps://www.googleapis.com/auth/drive.fileshttps://www.googleapis.com/auth/drive
- In my log, when
Who has access to the app:is installed asAnyone, I confirmed that from April 11, 2018, it is required to be shared the project to access to Web Apps. This might be due to the update of Google.
- Please share the project of Web Apps with users and try again.
- For the Web Apps server side, if you set
User accessing the web appforExecute the app as:, please authorize the scopes using own browser. This authorization is required to do only one time.
If these were not useful for your situation, I'm sorry.
answered Apr 26 at 0:03
Tanaike
18.5k2921
18.5k2921
Thanks ! You point me in the right direction. It seems that now, script B needs the Drive scopes and at least reading rights on script A to avoid 401 errors. I will clarify this in a new answer.
– Q_C
Apr 26 at 8:52
@Q_C Welcome. Recently, I summarized about Web Apps. If this is useful for you, I'm glad. github.com/tanaikech/…
– Tanaike
Apr 26 at 11:17
Excellent work, well done !
– Q_C
Apr 27 at 11:52
add a comment |
Thanks ! You point me in the right direction. It seems that now, script B needs the Drive scopes and at least reading rights on script A to avoid 401 errors. I will clarify this in a new answer.
– Q_C
Apr 26 at 8:52
@Q_C Welcome. Recently, I summarized about Web Apps. If this is useful for you, I'm glad. github.com/tanaikech/…
– Tanaike
Apr 26 at 11:17
Excellent work, well done !
– Q_C
Apr 27 at 11:52
Thanks ! You point me in the right direction. It seems that now, script B needs the Drive scopes and at least reading rights on script A to avoid 401 errors. I will clarify this in a new answer.
– Q_C
Apr 26 at 8:52
Thanks ! You point me in the right direction. It seems that now, script B needs the Drive scopes and at least reading rights on script A to avoid 401 errors. I will clarify this in a new answer.
– Q_C
Apr 26 at 8:52
@Q_C Welcome. Recently, I summarized about Web Apps. If this is useful for you, I'm glad. github.com/tanaikech/…
– Tanaike
Apr 26 at 11:17
@Q_C Welcome. Recently, I summarized about Web Apps. If this is useful for you, I'm glad. github.com/tanaikech/…
– Tanaike
Apr 26 at 11:17
Excellent work, well done !
– Q_C
Apr 27 at 11:52
Excellent work, well done !
– Q_C
Apr 27 at 11:52
add a comment |
up vote
2
down vote
accepted
Tanaike pointed me in the right direction. Apparently, some internal rules recently changed in the authentication mechanism for Apps Script deployed as a web app.
For B script, the default scope with UrlFetch is https://www.googleapis.com/auth/script.external_request, but it looks like we now need at least read access to A script, which means we also need Drive scopes.
In order to achieve that, you can for example have this function in B script to authorize them.
function setScope() {
DriveApp.getRootFolder();
}
add a comment |
up vote
2
down vote
accepted
Tanaike pointed me in the right direction. Apparently, some internal rules recently changed in the authentication mechanism for Apps Script deployed as a web app.
For B script, the default scope with UrlFetch is https://www.googleapis.com/auth/script.external_request, but it looks like we now need at least read access to A script, which means we also need Drive scopes.
In order to achieve that, you can for example have this function in B script to authorize them.
function setScope() {
DriveApp.getRootFolder();
}
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
Tanaike pointed me in the right direction. Apparently, some internal rules recently changed in the authentication mechanism for Apps Script deployed as a web app.
For B script, the default scope with UrlFetch is https://www.googleapis.com/auth/script.external_request, but it looks like we now need at least read access to A script, which means we also need Drive scopes.
In order to achieve that, you can for example have this function in B script to authorize them.
function setScope() {
DriveApp.getRootFolder();
}
Tanaike pointed me in the right direction. Apparently, some internal rules recently changed in the authentication mechanism for Apps Script deployed as a web app.
For B script, the default scope with UrlFetch is https://www.googleapis.com/auth/script.external_request, but it looks like we now need at least read access to A script, which means we also need Drive scopes.
In order to achieve that, you can for example have this function in B script to authorize them.
function setScope() {
DriveApp.getRootFolder();
}
answered Apr 26 at 9:03
Q_C
1788
1788
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f50021631%2fauthentication-issue-with-google-apps-script-deployed-as-a-web-app%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Did you tried doing the same using Postman/etc ?
– Mohammad Umair
Apr 25 at 12:00
Yes, I managed to reproduce this behavior using Insomnia.
– Q_C
Apr 25 at 12:04
What's the exact error message ? Earlier same setup & code was workin ?
– Mohammad Umair
Apr 25 at 12:08
401 Unauthorized. Yes, we have been using this authentication mechanism since several months without any issue.
– Q_C
Apr 25 at 12:15
Try publishing app with public access (Anyopne, even anonymous) see if that works, if that works, then make sure header is coming properly
– Mohammad Umair
Apr 25 at 13:08