Responses to the discussion on Github - Thread 1*
A very good catch. To avoid the installation process being more complicated, the secret could be maybe passed within cross-env, what do you think? It would be also commited though.
Not sure! Where would it be?
If it’s only in
develop script (not in
start script), it would be much safer and development environment installation would keep easy, right?
In package.json, within
start scripts. One would then remove it from
start script and pass the secret as a proper env variable in prod.
I think we should make some research how others handle this type of issue.
For instance, express-jwt doesn’t see any issue passing secret in code.
start script, it seems not to be a good ideia IMHO.
express-jwt doesn’t generate a secret silently in your source code, does it? It just shows an example of usage in docs, it isn’t an advice on how you should pass your secret.
What happens if someone accesses your source code and catches your jwt secret? They would be able to rewrite jwt payload and be authentic as any user. Right?
I was thinking about this issue and I come up with an idea of generating a gitignored file in the root dir which would contain the secret. It would be created upon server start if not present. @yagotome What do you think?
Well, adding secret in a file ignored by git solves the problem! But how other collaborators would make their setup? If I git clone the project, I’d need to create this file, right? It’s OK for me if it’s documented.
The file would be auto generated if not present upon server start. The secret key equality is necessary in multi node setup where multiple servers are able to process requests made by authenticated once users otherwise it doesn’t matter so each collaborator could have different secrets in their setup.
Great! Totally agree! So on deploy into a multi node server, one would only need to set their secret env so that all nodes in cluster have the same secret, right?
Almost! You would need to store the file along
.env and copy it to the project’s working directory upon update. If you don’t do this and you keep creating the file every time your app gets update, you invalidate your users bearer tokes.
No solution is perfect
Alright! But why not just lookup an env by default (such as
JWT_SECRET) and if not set, use secret from uncommitted generated file? This seems neater for me. What about you?
What about storing the secret key it in the DB?
Uncommitted file would reflect the value stored in the database, value itself would be changeable in the admin dash for convenience.