IssueTracker

better practice and documentation about this issue will be appreciated

Agreed, this is a must for me to securely pass information to a Google Webapp dopost function.  URL querystrings are not secure...

I see the request status has not changes for this item, is there a current update on if this feature will be implemented in the Google Webapp product?

I stopped using Apps Script because of it being unreliable. I'm working with Firebase now, which is a Google service with enhanced capabilities.

Not the most elegant solution but its possible to use cloud functions as a workaround. Here's a link to a post I created on the topic:
https://plus.google.com/u/0/109722946999133841016/posts/97iVtkSj6qi

pls!!!

+1 please

+1 pls!

+1 please

+1 pls

+1 please!!!

A message to the authors of the more recent posts,  "+1 please" comments don't really make a difference. If you really want to draw attention to this issue then you need to star it. Open the issue and click to the star at the top of the thread. The higher the "starred" count the more likely the devs at Google will notice this issue.

+1

+1

Please

+1

This is most important to access headers in doPost because of all of the modern system post a security token into the header in order to validate POst body.

+1

+1

Show-stopper for several projects. I've had to set up a webhook reflector to get around this odd limitation.

+1

Very hard using Shopify webhooks without access to the headers that specify what type of request is being triggered + validation.

+1

+1

+1

+1

+1

+10

+1000000000000000000 pls

+1

+1+1

please!!!

+1000

+1 because of Bitbucket Webhook

+1

+1

+1

+1

Is there anyone on this list who could bring this to someone at Google who can address? It's a pretty basic deficiency and a show-stopper for many scenarios.

+1

+1

+1 as another individual mentioned for shopify webhooks

+1

+1

+1 for me.  Super frustrating this isn't supported already. This issue has been live for 2.75 years.  Can we please get an update if it is even being considered by the api team?

+1

+1

+1

+1

+99999999999)

+1

Really needed, please implement - many services send headers containing tokens/signatures that cannot be accessed safely without the headers in doPost.

+1

+1

+1

+1

+1

+1

+1 pleeease!

+1 please!

+1

+1

Wow it has been years... please add headers to the event object. This makes use of webhooks very insecure and impossible to verify.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Dear Google Team and Developer,

To Process PayPal Webhooks it is absolutely necessary to get access to all HTTP header fields, at least to:

PAYPAL-TRANSMISSION-SIG
PAYPAL-AUTH-ALGO
PAYPAL-CERT-URL
TRANSMISSION-TIME

see: https://developer.paypal.com/api/rest/webhooks/

Maybe some additional header fields will be added by PayPal in the future or some will be changed.

For that reason to have access to all header fields would be appreciated and the proposed solution to add a "headers" key with corresponding values to the JSON parameter given to doGet() and doPost() would be the easiest solution.

This was already proposed on Oct 13, 2017 02:39PM by Alexe S Nau:

"I propose that the event object have a parameter called "headers" added to it with the requisite request headers stored as a key-value map. "


Since this Feature Request is from 2017 it may be time to give more attention to it.

Make us users and developers happy !

Greetings and best regards in hope that it will finally find the way to realisation in this year 2022

p.s.
Furthermore maybe other HTTP verbs would also be valuable?
https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Hello Google Team and Developers,

I have some thoughts about the headers field request in the doGet(e) and doPost(e) event JSON parameter e for http headers.

The formerly proposed field "headers" will result in inclusion of all header fields in every doGet(e) doPost(e) call.
Which results in a lot more data traffic especially for small data payloads it may result in an overhead.
And especially not every AppScript needs the header information.

It may be that a lot more data needs to be transported and you may want to prevent this.

Goal:
reduce data transferred if not necessary

Two scenarios need to be considered:
1.) dispatching to the correct Skript-ID is done NEAR the receiving Server
2.) dispatching to the correct Skript-ID is done FAR the receiving Server
(receiving server is the one receiving the http request NOT the AppScript Server where the script is running on)

In both scenarios following two steps are necessary:

a.) Setting in some way "httpheaders":"true" i the project settings, like mentioned in the following proposed solutions.
b.) As a prerequisite the request for headers need to be propagated to the receiving servers so they can decide to include headers or not.


I don't know your server infrastructure and at which point in the data flow the Script-ID / WebApp-ID is used to dispatch the data to the  corresponding AppsScript.

But somewhere in the data flow there must be somewhere a piece of code using the Script-ID to route the data.

Scenario 1:
If this happens near the receiving server, the following proposed solutions may help to reduce traffic even if http-headers are needed by some scripts (not every script need them).
Data reduction as early as possible, transmission only if necessary!

Scenario 2:
If the dispatching happens far from the server and distributed over the infrastructure it may be better just to include all headers in the doGet(e) doPost(e) event JSON every time.
No data reduction possible or reasonable for the last mile.


For the NEAR the Server Scenario (1) I propose two (and some variants) as a solution:


Firstly:
The header element in the event JSON is only a link or URL or a unique identifier.

Your servers will store the corresponding headers for some seconds in a volatile key:value store.

If a user/programmer really needs the headers one can request them using the link, URL or unique identifier to retrieve them separately with a function like:

getHeadersForEvent( scriptID, e.headersID);


+ Pros:
It will only send Data to the AppScript if requested.

- Cons:
you need a volatile and distributed key:value store and this means the header data needs to be transported anyway and in addition multiple times because it is distributed in your system.
This means: more traffic what should be prevented!



Secondly:
During deployment every AppScript is examined/scanned for needed access rights and if one want to deploy it as a WebApp, library, add-on etc. one is asked during deployment as well.


In this phase it could be determined if the script needs the HTTP header fields.
Only in this case they will be send inside the event JSON.

For instance a new function in the API can be implemented which one needs to call during initialisation of the script.
Something like:


PropertiesService.getScriptProperties().needHttpHeaders(true);

If the function is present your scan will reveal this and asking in a popup the user, similar to access rights, to explicitly request/grant it.

This will result in an entry like "httpheaders":"true" in the appsscript.json manifest like
i.e.

  "webapp": {
    "executeAs": "USER_DEPLOYING",
    "access": "MYSELF",
    "httpheaders":"true"  <<<<<<<<
  },
 
and similar for other scripts like bound-scripts or libraries and add-ons.

Or  place it in the dependencies:

{
  "timeZone": "America/New_York",
  "dependencies": {
       
        "http":{.                          <<<<<<<<
          "httpheaders":"true",  <<<<<<<<
          "version":"1.1".       <<<<<<<< maybe in future necessary to distinguish http 1.0, 1.1, 2.0 and so on
         },
         
        },
  "webapp": {
    "executeAs": "USER_DEPLOYING",
    "access": "MYSELF"
  },
  "exceptionLogging": "STACKDRIVER",
  "runtimeVersion": "V8"
 
}


Maybe it is even not needed to implement the function:

        PropertiesService.getScriptProperties().needHttpHeaders(true);

if your scann code is clever enough and can determine it in an other way.


Only if required the headers will be included in the event JSON.

+ Pros:
No unnecessary data is transferred, only if needed.
No extra key:value store is needed.
It could be automated for scripts, if scrips need it they can say so and will get them.

- Cons:
The implementation on your side will probably be a little bit more challenging.


To make it even easier for you to implement it:

One solution to make it more easy to implement on your side is using the project settings.

An script user/ developer can set explicitly the requirement, resulting in the insertion of "httpheaders":"true" in the appsscript.json

In this case your automatic scan need not to detect it and so this scan-code needs not to be adapted.
Furthermore there is no need for a function like  "needHttpHeaders(true)".


Would this be a way to easily implement it?
Let me know.

Greetings and best regards

please make this happen google!

+1

My use case is for a Slack event subscription that is handled by a Google App Script web app.
Event subscriptions will retry until a 200 response is provided by the client app, and Google App Script web apps sometimes do not resolve doPost functions fast enough before Slack resents.

The resend count information is found in the header of the POST request from Slack, however, so a known solution for slow services is available:
https://stackoverflow.com/questions/50715387/slack-events-api-triggers-multiple-times-by-one-message

If doPost event passed headers, I could also rectify this in my web app.

Thank you for your hard work.

In response to a question about this thread, I got the following response from an Engineer in google (several layers away from me, not a direct conversation):

"They can set the webhook as a Cloud function and modify the incoming request. Then send to appscript deployed api."

I believe this means, "create a cloud function in lieu of your doPost function in apps script;  read the headers via the cloud function and then use them to call your appscript functions via the apps script api (https://developers.google.com/apps-script/api/how-tos/execute)".

It certainly sounds like it should work, but I haven't had time to try it yet.

Hello,

as I understand one should use another service to solve the problem. not having access to http headers form App-Script.

This may work for skilled programmers familiar with Cloud functions but for an average user with a little bit of scripting knowledge this seems a litte bit too cumbersome.

Also every User who needs access to some header fields need to re-implement all the stuff in Cloud functions.

It would be much more convenient and less error prone if google would support such functionality out of the box, tested and error free.

As I already wrote a while ago, if increase of traffic is a concern while delivering every time the http header, google can just have a setting in the manifest file and only supply http headers if needed by the App-Script.
Several ways to implement this where presented.

Maybe two additional functions (delivering body and headers the ...H() )
doGetH()  
doPostH()

are ideal to be implemented, because backward compatibility are preserved and new scripts can be scanned for occurrence of these two functions and the manifest adapted accordingly. In this way the backend system knows that http headers should be delivered to the App-Script.

Greetings

I completely agree with https://issuetracker.google.com/issues/67764685#comment87 and it is a shocking omission on the part of the Google engineers.  However, the workaround is better than nothing in my opinion, assuming that you wish to continue using google apps script.  

This would be very usefull to me too.

+1

+1+1+1+1

++++

+1

+1 ( I want to handle GitHub webhooks safely )

+1

+1

+1

+1

Up

+1

+1

+1. Its been years....

+1

+1 missing basic functionality

missing basic functionality

For the amusement of those frustrated by this (definitely I am).

I asked chatGPT and it asserted, with an authoritative sounding air that something like this would work:

var contentType = e.parameter.headers["Content-Type"];

For sure!  It would be nice though if Google Engineers could do something like that.

Not a particularly hopeful status update, though. 'New', even though it's been over 5 years? And now no one at Google is assigned to it, so it feels as though this one is going into the black abyss...

I'm beginning to think that the reason why this isn't implemented yet is because of the security implications; how much data about the requestor ends up being sent in the request header that Google doesn't want our scripts to see? Maybe the challenge is deciding how to filter out sensitive information, while still letting the important bits through.

we need thisssssssss!!!!please

+1

+1

+1

+1

We need this for using the WhatsApp webhook.

+1

+1

+1

It is great to see that this issue is now assigned to Google after many years of waiting.  Is it possible to get a rough sense of the timeline for the next update?  

+1 I'm using an Apps Script as a callback for the Google Calendar webhook to process changed events, but I can't see which event was changed as the event ID is passed in the request header. Spent a long time writing the script on the assumption this would be possible.

This feature is so suitable. In my case, I need to check up on a signature sent as a header to implement a security feature.

+1

+1 want it for slack

I need to check up on a signature sent as a header to implement a security feature.

I also have a use case where I actually need to access the headers but doPost doesn't retrieve the headers from the request. I don't wish to change the functionality of doPost unless it's made backward compatible; however, if it's possible allow doPost to have two parameters instead of one so that all the previous code that used doPost will not be impacted where the new parameter is for the headers.. :)

Thanks!