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.
Author
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 develop
& 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.
Author
In 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?
Author
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.
Author
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
Author
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.
Author
LGTM