Allow specifying configuration params in env vars#83
Allow specifying configuration params in env vars#83djmitche merged 2 commits intoGothenburgBitFactory:mainfrom
Conversation
ryneeverett
left a comment
ryneeverett
left a comment
There was a problem hiding this comment.
Since we already broke cli backwards compatibility in #81, could we consider removing --allow-client-id as a command line argument? If we're treating it as a credential then we shouldn't encourage passing it this way.
| assert_eq!(*matches.get_one::<i64>("snapshot-days").unwrap(), 13i64); | ||
| assert_eq!(*matches.get_one::<u32>("snapshot-versions").unwrap(), 20u32); |
There was a problem hiding this comment.
Seems odd that these end up with such different types.
There was a problem hiding this comment.
I don't remember if I had a reason for that, but I don't think it's too important.
README.md
Outdated
| By default, the server allows all client IDs. To limit the accepted client IDs, | ||
| such as when running a personal server, use `--allow-client-id <client-id>`. | ||
| This value can be specified in the environment variable `CLIENT_ID`, as a | ||
| comma-separated list of client IDs. |
There was a problem hiding this comment.
Might be nice to mention that the client id should be treated as a credential since it may not be obvious that the client id is the only authentication.
I mentioned it in the README. But, I don't think this is a critical distinction in a lot of deployments, which are running on a VPS or some other sort of single-user system. |
2 participants
Fixes #73.
This updates the docker-compose to use the new format as well.