Question
How to pass an editable list of configuration keys/values to a bitbucket function?
- Posted on April 14, 2023
- DigitalOcean Functions
Asked by Leon Szkliniarz
I’m looking for some method of passing an array of ids and associated tokens to a DO function.
Ideally the above should not require either redeploying the DO function to add an id/token, does not put the sensitive tokens in a repository and does not use some external service to manage them. I would like it to be manageable via the DO admin pages if at all possible.
Details below in case this is an X/Y problem.
Background:
I’ve developed a DO function as a bit of glue between two services - the function acting as a webhook that takes in a request from one service, validates it’s actually from that service using a signature token and then uses the data POSTed to it to make a few POST requests to another service.
I’m currently passing this signature token to the DO function via environment variables set in the DO functions admin pages. This has been working great on my test bed.
The problem:
Turns out the signature token isn’t for an account on the service, it’s for a project in that account. So my function that works great for one project will not work for multiple (and it needs to). This signature token is is not controllable by us in any way, shape or form.
However, the requests sent to the DO function do at least include the ID of the project so I can use that to look up which signature token to use for validation. I’m passing the token in as an environment variable at the moment. They have to be strings and I need to provide a list or key/value of some description.
Work-arounds I’ve considered:
1: Make the environment variable string into JSON
This would work, except that there doesn’t appear to be any way to actually edit the environment variable via the DO functions admin pages. There’s a raw editor that lists the keys, but the values are encrypted.
2: Have one instance of a function per key
This would side-step the problem by just having the same function a few times with different environment variables. Unfortunately, in my ignorance I can’t see any way to this that isn’t horrendously messy.
Are there any better solutions available here?
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.
There are a few different ways to get data into a function invocation.
Deploy time params: These are parameters you can set at deploy time. They will be available as top level properties of the event parameter. This is useful for static information like the map of projects to signature tokens that you want to use during each invocation to validate the input.
Invoke time params (non-web): Like above, except you provide them each time you invoke the function with the REST API or with
doctl sls fn invokeusing--param, instead of providing the data at deploy time to be re-used in invocations that occur after the deployment. The data is parsed and placed at the top level of the event parameter.Invoke time params (web): Like above, except you invoke the function as a web function (e.g. via curl or any other HTTP client) and provide JSON data in the HTTP request body.
Of these options, the one that I think you need to use for your use case is #1. You wouldn’t use #2 or #3 because the data you need to use in your function is provided by you as configuration that is used throughout multiple invocations, not by one of your users as input for just one invocation.
I do notice that you want a solution that involves being able to update this data without having to re-deploy. I think that in order for you to achieve this, you would have to build some other service, probably involving a database, that this function would query when it starts, and perhaps poll while it runs if it stays warm for a long because it’s invoked frequently. With the function alone, you’d need to re-deploy it each time to update this configuration data.