Spectrum: Help regarding Secrets

[entrptaher]

We want to run it on server with our own domain name and not on localhost. It seems there are several cavets regarding the secrets and I couldn't find a proper guide for them, the deployment guide doesn't talk about env variables.

Unused variables

I've searched and saw there are several unused variables on now.json file. These are following,

• COMPOSE_RETHINKDB_PASSWORD
• COMPOSE_RETHINKDB_URL
• COMPOSE_RETHINKDB_PORT
• OPTICS_API_KEY
• APOLLO_ENGINE_API_KEY (commented out on code)

Conflicting variables

There are several ENV variables that's being misleading since they are spread and mean same thing. Or needs more clarification.

• REDIS_CACHE_URL points to @redis-labs-url, COMPOSE_REDIS_URL points to @compose-redis-url, both are used in several files across the repo. Can we use same info for both?

Doubtful variables

• There is also no mention if we must provide STRIPE, TWITTER, FACEBOOK, SLACK, GOOGLE, GITHUB, SENTRY etc secrets.
• SPECTRUM_MODERATION_API_KEY, Is it specific to your company? If yes, how do we get it?
• POSTMARK_SERVER_KEY, must we use postmark for this?

Not sure if deployment will fail if we don't provide one of the specified secrets.

[brianlovin]

@entrptaher most of these are up to you, but I'll clarify your questions:

• compose, optics, and apollo engine you don't need
• we use the redis-labs-url to store cached versions of html for signed-out users
• we use compose redis for our job queue
• you could use any redis store you want, doesn't need 2 providers :)
• you don't need to provide stripe if you're not doing payments
• you don't need sentry if you are not worried about bug reporting
• you don't need twitter, fb, google, or github secrets if you don't plan to provide social auth
• you don't need slack if you don't plan to support slack invitations
• spectrum_moderation_api_key is specific to us + a partner provider
• you can use any email provider in place of postmark, but all of our code uses the postmark api so you'd have to redo those to match whatever provider you want

Overall: everything is optional if you're planning to fork this and customize it for your own use case :) You may run into problems self hosting the code as-is if you want to use alternative providers or not support certain features.

[entrptaher]

@brianlovin It asked for both aws and compose, I didn't put any secrets yet, but should I put both aws and compose there? :/

[brianlovin]

You'd need those configured in your now-secrets.json as well as be setting them up with now secrets add in the now-cli - hope that makes sense :)

[entrptaher]

Still since it is asking for both aws and compose keys, that's what is misleading me. So I should actually put rethinkdb url and password from both compose and aws? :/ Can I not use same details for both?

[brianlovin]

For compose-rethinkdb-password and compose-rethinkdb-port you can just put any random string - those aren't actually used anywhere in the code anymore afaik. The aws-rethinkdb-password and aws-rethinkdb-url you'll need those to be real connections to a db - if you're forking this and want to use a different provider you can swap all of that out as you need :)

[entrptaher]

I'm gonna close this issue for now. Looks like this is dependent on many internal stuff.

[M3kH]

I would like to reopen this issue.
The env variables can be provided without conflicting the current local workflow.

I did some work already on this direction, but maybe worth to consider having a .env file for development and use something like dotenv to expose in the runtime.
What do you think @brianlovin ?

[entrptaher]

We are already doing this on our fork and proposed the same.
Here are some .env contents we are using,

PROD_DOMAIN="community.vanila.io"
REACT_APP_PROD_DOMAIN="community.vanila.io"
REACT_APP_SLACK_CLIENT_DEVELOPMENT="548379673607.565684711798"
REACT_APP_VAPID_PUBLIC_KEY="BGd6koDFMvFetgvWYGSyb84AyyhqLDkFIlfrcAyytHsRJsmrT_LEDB7c_5SK0Mt7ztJuYs-y5C7Ey0EC9Y3I90k"

As you can see, all of the content mentioned here can be public without any problem. It will let us remove some hardcoded links.

@M3kH wanna contribute?

[mxstbr]

We already use now-secrets.json no need to duplicate the information in a .env file. The now-secrets.json file fulfils the same purpose.

[M3kH]

@mxstbr a .env file would just provide default value when not provided; handy for the development environment.

Not that much to maintain.

[mxstbr]

cp now-secrets.example.json now-secrets.json does that already. That's what the now-secrets.example.json file is for, setting defaults.

[M3kH]

cp now-secrets.example.json now-secrets.json does that already. That's what the now-secrets.example.json file is for, setting defaults.

With the little difference that a lot of env options are not configurable in the local experience.
Eg: REDIS_CACHE_URL and others.

if now-secrets.example.json is the way to go, that is also fine, but IMO there is still some work to be done also with that.

No worth discuss equivalent solutions for different file. :-)

But is good to point out that a there is a lot of conditions how the config variables behaves in dev vs prod; maybe is worth just talk about how to normalise that discrepancy.

[mxstbr]

That is independent of whether to use a .env file or the now-secrets.json file 😉 If you can point to some specific bugs please open a new issue and we can discuss adjusting the secrets structure!

[M3kH]

Sure for instance, in the PR #4846 you can see all the changed files are just about some env config that are missing to be passed.
That might be just a start.

[entrptaher]

@mxstbr, actually now-secrets does not work for your react frontend. I already made a thread about it on spectrum and Zeit.

If you want, i can create a new issue out of it but it's uptown you guys to make the recession whether you want to hardcode VAPID KEY or SLACK PUBLIC key.

Here are the links for you,

• https://spectrum.chat/spectrum/general/now-env-on-create-react-app~38ff116c-3379-4d51-a5c9-4e709b1da49a