I have been debugging an error with a Function to handle webhooks.
I verify the expected payload of the webhooks with key/signatures.
DigitalOcean is writing their own information into the payload (e.g. __ow_headers, __ow_path, __ow_method).
Although this information is useful, as they are manipulating the payload any verification that I do will fail.
My preferred option is to just access the raw payload which was sent by the originator. Does anyone know how to do this in Python using DigitalOcean Functions?
My backup is to strip out the information I need, however if DigitalOcean or my originator change the payload then the code will break, for this reason it is not preferred.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Click below to sign up and get $200 of credit to try our products over 60 days!
Enter your email to get $200 in credit for your first 60 days with DigitalOcean.
If you want to have the raw request body sent by the client come through in your event parameter (the first parameter of your Python function), there are a few options.
One is to use
rawas the value of your
websetting in your project’s
For example, the Python starter code (when generated with
doctl sls init) includes a
project.ymlfile that looks like this:
If you change it to this:
And then deploy, you’ll notice that the event parameter looks different:
Notice how there is a property called
http.body. This is the raw HTTP body that the client sent. It sounds to me like this would be a good way to solve your use case if you want to use this escape hatch to disable the HTTP request parsing that DO does before calling your function code.
One thing you’ll notice too when using
web: rawmode is that if your content type is one associated with binary data (like
application/octet-stream), then the request body will be Base64-encoded:
So even when you’re sending binary data instead of text data, this escape hatch will work when you want access to the raw request body.
Note, however, that Functions currently doesn’t support streaming. The request body must be able to fit in the memory you provision for your function because the Functions runtime will attempt to deserialize it into a Python dict in memory when your function is invoked.
If you want to fall back to your backup plan to strip out the properties other than ones you want in your data model, I think this is a good option too. I know you stated that your code might break in the future if you do this, but you might be able to put together something stable depending on the details of your use case.
For example, if you have the following JSON Schema used to validate your event parameter:
Then it is true that the event passed in would fail this validation. The event coming in might look like:
httpmake it fail this validation.
But you could then transform the event to one that only has the properties you know you need for your validation:
Then, if you validated it, the extra properties provided by the Functions runtime wouldn’t cause validation to fail.
This example used JSON Schema for validation, but this concept should apply to any validation done by you or frameworks you use that use the event data.