switch to generating the INTERNAL_COMMAND_TOKEN

Author: kentcdodds

.env.example

@@ -4,10 +4,12 @@ DATABASE_URL="file:./data.db?connection_limit=1"
 CACHE_DATABASE_PATH="./other/cache.db"
 SESSION_SECRET="super-duper-s3cret"
 HONEYPOT_SECRET="super-duper-s3cret"
-INTERNAL_COMMAND_TOKEN="some-made-up-token"
 RESEND_API_KEY="re_blAh_blaHBlaHblahBLAhBlAh"
 SENTRY_DSN="your-dsn"
 
+# this is set to a random value in the Dockerfile
+INTERNAL_COMMAND_TOKEN="some-made-up-token"
+
 # the mocks and some code rely on these two being prefixed with "MOCK_"
 # if they aren't then the real github api will be attempted
 GITHUB_CLIENT_ID="MOCK_GITHUB_CLIENT_ID"

docs/decisions/037-generated-internal-command.md

@@ -0,0 +1,44 @@
+# Generated Internal Command Env Var
+
+Date: 2024-06-19
+
+Status: accepted
+
+## Context
+
+There are use cases where your application needs to talk to itself over HTTP.
+One example of this is when a read-replica instance needs to trigger an update
+to the cache in the primary instance. This can be done by making an HTTP request
+to the primary instance.
+
+To secure this communication, we can use a secret token that is shared between
+the instances. This token can be stored in the environment variables of the
+instances.
+
+Originally, this token was manually generated once and set as a secret in the
+Fly app. This token was then used in the application code to authenticate the
+requests.
+
+However, this manual process is error-prone and can lead to security issues if
+the token is leaked.
+
+An alternative is to generate the token in the Dockerfile and set it as an
+environment variable in the Fly app. This way, the token is generated
+automatically and is unique for each deployment.
+
+One drawback to this is during the deployment process, an old replica might
+still be running with the old token. This can cause issues if the new replica is
+expecting the new token. However, this should be short-lived and it's also
+possible the read replica is running out-of-date code anyway so it may be to our
+benefit anyway.
+
+## Decision
+
+We will generate the internal command token in the Dockerfile and set it as an
+environment variable in the Fly app.
+
+## Consequences
+
+We'll need to remove the steps during initial setup and the documentation
+instructions. This will simplify the setup process and reduce the risk of
+security issues due to leaked tokens.

docs/deployment.md

@@ -55,12 +55,12 @@ Prior to your first deployment, you'll need to do a few things:
   [your repo secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
   with the name `FLY_API_TOKEN`.
 
-- Add a `SESSION_SECRET`, `INTERNAL_COMMAND_TOKEN`, and `HONEYPOT_SECRET` to
-  your fly app secrets, to do this you can run the following commands:
+- Add a `SESSION_SECRET` and `HONEYPOT_SECRET` to your fly app secrets, to do
+  this you can run the following commands:
 
   ```sh
-  fly secrets set SESSION_SECRET=$(openssl rand -hex 32) INTERNAL_COMMAND_TOKEN=$(openssl rand -hex 32) HONEYPOT_SECRET=$(openssl rand -hex 32) --app [YOUR_APP_NAME]
-  fly secrets set SESSION_SECRET=$(openssl rand -hex 32) INTERNAL_COMMAND_TOKEN=$(openssl rand -hex 32) HONEYPOT_SECRET=$(openssl rand -hex 32) --app [YOUR_APP_NAME]-staging
+  fly secrets set SESSION_SECRET=$(openssl rand -hex 32) HONEYPOT_SECRET=$(openssl rand -hex 32) --app [YOUR_APP_NAME]
+  fly secrets set SESSION_SECRET=$(openssl rand -hex 32) HONEYPOT_SECRET=$(openssl rand -hex 32) --app [YOUR_APP_NAME]-staging
   ```
 
   > **Note**: If you don't have openssl installed, you can also use
@@ -190,7 +190,14 @@ node application (on port 8081).
 Helpful commands:
 
 ```
-docker build -t epic-stack . -f other/Dockerfile --build-arg COMMIT_SHA=`git rev-parse --short HEAD` # builds the docker container
-mkdir ~/litefs # mountpoint for your sqlite databases
-docker run -d -p 8081:8081 -e SESSION_SECRET='somesecret' -e INTERNAL_COMMAND_TOKEN='somesecret' -e HONEYPOT_SECRET='somesecret' -e FLY='false' -v ~/litefs:/litefs epic-stack     # Runs the docker container. http://localhost:8081 should now point to your docker instance. ~/litefs directory has the sqlite databases
+# builds the docker container
+docker build -t epic-stack . -f other/Dockerfile --build-arg COMMIT_SHA=`git rev-parse --short HEAD`
+
+# mountpoint for your sqlite databases
+mkdir ~/litefs
+
+# Runs the docker container.
+docker run -d -p 8081:8081 -e SESSION_SECRET='somesecret' -e HONEYPOT_SECRET='somesecret' -e FLY='false' -v ~/litefs:/litefs epic-stack
+
+# http://localhost:8081 should now point to your docker instance. ~/litefs directory has the sqlite databases
 ```

other/Dockerfile

@@ -61,6 +61,7 @@ ENV DATABASE_PATH="$LITEFS_DIR/$DATABASE_FILENAME"
 ENV DATABASE_URL="file:$DATABASE_PATH"
 ENV CACHE_DATABASE_FILENAME="cache.db"
 ENV CACHE_DATABASE_PATH="$LITEFS_DIR/$CACHE_DATABASE_FILENAME"
+ENV INTERNAL_COMMAND_TOKEN=$(openssl rand -hex 32)
 ENV INTERNAL_PORT="8080"
 ENV PORT="8081"
 ENV NODE_ENV="production"

remix.init/index.mjs

@@ -37,12 +37,10 @@ export default async function main({ rootDirectory }) {
 		fs.readFile(PKG_PATH, 'utf-8'),
 	])
 
-	const newEnv = env
-		.replace(/^SESSION_SECRET=.*$/m, `SESSION_SECRET="${getRandomString(16)}"`)
-		.replace(
-			/^INTERNAL_COMMAND_TOKEN=.*$/m,
-			`INTERNAL_COMMAND_TOKEN="${getRandomString(16)}"`,
-		)
+	const newEnv = env.replace(
+		/^SESSION_SECRET=.*$/m,
+		`SESSION_SECRET="${getRandomString(16)}"`,
+	)
 
 	const newFlyTomlContent = flyTomlContent.replace(
 		new RegExp(appNameRegex, 'g'),