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