Page MenuHomePhabricator

[landing][keyserver] Allow setting Alchemy key in keyserver/.env
ClosedPublic

Authored by ashoat on Dec 30 2022, 7:57 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Nov 27, 4:27 PM
Unknown Object (File)
Mon, Nov 11, 1:03 PM
Unknown Object (File)
Wed, Nov 6, 6:32 AM
Unknown Object (File)
Tue, Nov 5, 10:01 PM
Unknown Object (File)
Sat, Nov 2, 7:36 PM
Unknown Object (File)
Sat, Nov 2, 7:36 PM
Unknown Object (File)
Sat, Nov 2, 7:36 PM
Unknown Object (File)
Sat, Nov 2, 7:34 PM
Subscribers

Details

Summary

This will get downloaded to clients and isn't obfuscated or anything.

We prefer to have clients call Alchemy directly so we don't get any unnecessary user data.

If we end up concerned later that somebody is stealing our API key, we can reset it to another one and roll out some better obfuscation via a Webpack plugin or something.

Depends on D6112

Task is ENG-1282

Test Plan

I tested the Docker keyserver build, setting COMM_ALCHEMY_KEY in keyserver/.env and making sure that the key was set in both server-side and client-side rendering contexts

Diff Detail

Repository
rCOMM Comm
Branch
ashoat/siwe
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

keyserver/Dockerfile
23

This causes $COMM_ALCHEMY_KEY is be available as an env var to all of the build commands below

keyserver/docker-compose.yml
10

This pulls the env variable COMM_ALCHEMY_KEY (from env_file below) and declares it as an arg for the Dockerfile above

landing/.eslintrc.json
6

Without this change ESLint was erroring on our use of process.env. We have the same thing in web

landing/webpack.config.cjs
82

Here we pass the env variable from the build into both SSR and browser bundles via webpack.DefinePlugin

Little hesitant about this approach where the key is hardcoded in (even if obfuscated)... but if it's solely for rate limiting and doesn't grant any additional permissions or anything I guess it's fine

This revision is now accepted and ready to land.Dec 30 2022, 11:41 AM