Proposal for Managing API Keys

dreed47 commented

2025-03-31 16:32:49 +00:00

(Migrated from github.com)

Proposal for Managing API Keys

Step 1: Implement API proxies for all interfaces requiring an API key. The Git repository for these proxies should include a /secrets folder, which will be ignored by Git (i.e., its contents are not checked into the repository). This folder will store files containing the application’s API keys.

Step 2: Set the API key values in config.system.h to a default placeholder string, such as:

#define WEATHER_VISUALCROSSING_API_KEY "VISUALCROSSING_DEFAULT_API_KEY"

Step 3: In the proxy code, check if the API key matches the default placeholder string. If it does, replace it with the corresponding API key from the file in the /secrets folder (e.g., /secrets/VISUALCROSSING_DEFAULT_API_KEY).

If a user prefers to provide their own API key, they can simply define it in their config.h file, like so:

#define WEATHER_VISUALCROSSING_API_KEY "123456789123456789"

Deployment Note: When deploying the proxies, the API keys stored in the /secrets folder must be added manually or via a deployment script.

Proxies also have the side benefits of allowing caching of results, rate limiting, API retries if needed, and reducing JSON return size if needed.

Note: An example of proxy code here.

**Proposal for Managing API Keys** **Step 1:** Implement API proxies for all interfaces requiring an API key. The Git repository for these proxies should include a `/secrets` folder, which will be ignored by Git (i.e., its contents are not checked into the repository). This folder will store files containing the application’s API keys. **Step 2:** Set the API key values in `config.system.h` to a default placeholder string, such as: ```c #define WEATHER_VISUALCROSSING_API_KEY "VISUALCROSSING_DEFAULT_API_KEY" ``` **Step 3:** In the proxy code, check if the API key matches the default placeholder string. If it does, replace it with the corresponding API key from the file in the `/secrets` folder (e.g., `/secrets/VISUALCROSSING_DEFAULT_API_KEY`). If a user prefers to provide their own API key, they can simply define it in their `config.h` file, like so: ```c #define WEATHER_VISUALCROSSING_API_KEY "123456789123456789" ``` **Deployment Note:** When deploying the proxies, the API keys stored in the `/secrets` folder must be added manually or via a deployment script. Proxies also have the side benefits of allowing caching of results, rate limiting, API retries if needed, and reducing JSON return size if needed. Note: [An example of proxy code here.](https://github.com/dreed47/info-orbs-api-proxies)

flattermann commented

2025-03-31 19:50:18 +00:00

(Migrated from github.com)

I would just leave it empty to use the default key

// Set your own API key (leave empty for the default API key)
#define WEATHER_VISUALCROSSING_API_KEY  ""

On the proxy side, I would recommend using environment variables for the secret API key.
That's easier to manage and use than file based keys.

It should be as easy as this:
default_api_key = os.getenv('WEATHER_VISUALCROSSING_API_KEY')

The env variables for the proxies can then be set in the render.com dashboard.

I would just leave it empty to use the default key ``` // Set your own API key (leave empty for the default API key) #define WEATHER_VISUALCROSSING_API_KEY "" ``` On the proxy side, I would recommend using environment variables for the secret API key. That's easier to manage and use than file based keys. It should be as easy as this: `default_api_key = os.getenv('WEATHER_VISUALCROSSING_API_KEY')` The env variables for the proxies can then be set in the render.com dashboard.

dreed47 commented

2025-03-31 21:58:54 +00:00

(Migrated from github.com)

I'm fine with environment variables. It's a less secure as it bakes the keys into the docker image and could be discovered with a docker inspect but for our use case the improved usability probably outweighs any potential risk.

For the default key about about a generic "DEFAULT_KEY" instead of empty? Just trying to make it easier on the proxy side to know when it needs to swap the keys.

// Set your own API key (leave empty for the default API key)
#define WEATHER_VISUALCROSSING_API_KEY "DEFAULT_KEY"

I'm fine with environment variables. It's a less secure as it bakes the keys into the docker image and could be discovered with a docker inspect but for our use case the improved usability probably outweighs any potential risk. For the default key about about a generic "DEFAULT_KEY" instead of empty? Just trying to make it easier on the proxy side to know when it needs to swap the keys. // Set your own API key (leave empty for the default API key) #define WEATHER_VISUALCROSSING_API_KEY "DEFAULT_KEY"

flattermann commented

2025-03-31 22:26:47 +00:00

(Migrated from github.com)

I'm not sure why you think that env vars should be less secure than secret files. But I agree, both should be fine and deployable via render.com.

If we leave the API key empty by default, we can easily check for this in the proxy. I don't see an advantage of using a magic string ("DEFAULT_KEY") here.

I'm not sure why you think that env vars should be less secure than secret files. But I agree, both should be fine and deployable via render.com. If we leave the API key empty by default, we can easily check for this in the proxy. I don't see an advantage of using a magic string ("DEFAULT_KEY") here.

dreed47 commented

2025-04-01 02:12:50 +00:00

(Migrated from github.com)

I mean that env vars are built into the docker image so anyone who has access to the image can view the env vars that are set. e.g.
docker exec -it info-orbs-api-proxies-proxy-1 ps e -ww -p 1

Secrets read from a file are brought in at run time so they are not baked into the docker image. In our case we're not dealing with really sensitive data so it's not really a big risk.

I mean that env vars are built into the docker image so anyone who has access to the image can view the env vars that are set. e.g. ```docker exec -it info-orbs-api-proxies-proxy-1 ps e -ww -p 1 ``` Secrets read from a file are brought in at run time so they are not baked into the docker image. In our case we're not dealing with really sensitive data so it's not really a big risk.

dreed47 commented

2025-04-01 02:56:28 +00:00

(Migrated from github.com)

Here is an updated approach description.

Proposal for Managing API Keys

Step 1: Implement API proxies for all interfaces requiring an API key. These proxies will retrieve API keys from Docker environment variables defined in the deployment environment (e.g., via a .env file or Docker Compose configuration).

Step 2: Set the API key values in config.system.h to an empty string as the default, such as:

#define WEATHER_VISUALCROSSING_API_KEY ""

Step 3: In the proxy code, check if the API key is an empty string. If it is, replace it with the corresponding API key retrieved from the Docker environment variable (e.g., WEATHER_VISUALCROSSING_API_KEY defined in the environment).

If a user prefers to provide their own API key, they can define it in their config.h file, like so:

#define WEATHER_VISUALCROSSING_API_KEY "123456789123456789"

Deployment Note: When deploying the proxies, the API keys must be set as Docker environment variables manually or via a deployment script (e.g., in a .env file or passed directly to the Docker container).

This allows a setting similar to this:

#define TIMEZONE_API_URL "https://PROXY-HOST/timezone/proxy"

#define STOCK_API_URL "https://PROXY-HOST/twelvedata/proxy"
#define STOCK_API_KEY ""

#define WEATHER_VISUALCROSSING_API_URL "https://PROXY-HOST/visualcrossing/proxy"
#define WEATHER_VISUALCROSSING_API_KEY ""

#define TEMPEST_PROXY_URL "https://PROXY-HOST/tempest/proxy"
#define WEATHER_TEMPEST_API_KEY ""

#define WEATHER_OPENWEATHERMAP_API_URL "https://PROXY-HOST/openweather/proxy"
#define WEATHER_OPENWEATHERMAP_API_KEY ""

#define PARQET_PROXY_URL "https://PROXY-HOST/parqet/proxy"

Here is an updated approach description. **Proposal for Managing API Keys** **Step 1:** Implement API proxies for all interfaces requiring an API key. These proxies will retrieve API keys from Docker environment variables defined in the deployment environment (e.g., via a .env file or Docker Compose configuration). **Step 2:** Set the API key values in config.system.h to an empty string as the default, such as: `#define WEATHER_VISUALCROSSING_API_KEY ""` **Step 3:** In the proxy code, check if the API key is an empty string. If it is, replace it with the corresponding API key retrieved from the Docker environment variable (e.g., WEATHER_VISUALCROSSING_API_KEY defined in the environment). If a user prefers to provide their own API key, they can define it in their config.h file, like so: `#define WEATHER_VISUALCROSSING_API_KEY "123456789123456789"` Deployment Note: When deploying the proxies, the API keys must be set as Docker environment variables manually or via a deployment script (e.g., in a .env file or passed directly to the Docker container). This allows a setting similar to this: ```bash #define TIMEZONE_API_URL "https://PROXY-HOST/timezone/proxy" #define STOCK_API_URL "https://PROXY-HOST/twelvedata/proxy" #define STOCK_API_KEY "" #define WEATHER_VISUALCROSSING_API_URL "https://PROXY-HOST/visualcrossing/proxy" #define WEATHER_VISUALCROSSING_API_KEY "" #define TEMPEST_PROXY_URL "https://PROXY-HOST/tempest/proxy" #define WEATHER_TEMPEST_API_KEY "" #define WEATHER_OPENWEATHERMAP_API_URL "https://PROXY-HOST/openweather/proxy" #define WEATHER_OPENWEATHERMAP_API_KEY "" #define PARQET_PROXY_URL "https://PROXY-HOST/parqet/proxy" ```

Rows
Columns

Proposal for Managing API Keys #316