Coding Shorts: I Think We Can Do Better Than User Secrets

[@dvsdean]

I really enjoy your coding shorts. They are both informative and well made. Your deliver style is very polished. I love how you slowly but clearly explain things. Often others rush the code examples and don't highlight the reasons why things are done a certain. When you explain things it sinks in and it doesn't feel like I'm being assaulted. It's obvious that you care about the how you deliver your content as well as the content itself. Thanks for sharing and all you've done for the developer community. I'm always appreciative of your time and efforts. You stand apart from the rest.

[@tiesmaster]

This is really amazing!! I didn't felt the need to use user secrets in my professional project. Instead, we were using KeyVault to load all our secrets. However, in a recent personal project I did had that need, and I didn't even realize the clunkiness of user secrets, as I used it before, and just accepted it. This is really inspiring and convincing, and I'm gonna use it there as soon as possible. Thank you!!

[@josephizang6187]

You are not wrong. User Secrets is one example of why OSS community doesn't like microsoft things. .env should have been embraced from the start.I am glad you feel just like I do on this matter. Cheers

[@Wouldntyouliketoknow2]

Good observations. I have also struggled with the same problem of essentially keeping / maintaining a helpful template for user secrets. Often I just put something in a readme but this can easily fall out of line over time as secrets come and go. The issue is that secrets require some documentation to explain what they are and why you would set them - for example which ones are mandatory and which ones are optional.. it would be best if this was kept as close as possible to the actual secrets config. I can see env.sample being better because its visible in the repo and serves as that template (with comments) and is close (right next to) where you would want to add a new secret so you remember to update the env.sample at the same time. Dotnet secrets is lacking in this area. At the same time moving to dotenv approach could be problematic. For example Microsofts docker tooling for projects will do things like copy the user secrets file to be mounted in the container so when debugging in docker your secrets take effect in the container. If using dotenv files you'll have to work stuff like that out but I'm sure it may be even easier given it sits with your source code and not in some external directory.

[@timrobertson8242]

I had been looking for a targeting discussion about protecting Secrets, such as Database Connections and this really explored this very well. I have been using dotnet user-secrets, but changed the "Path" to match the Project or Solution Name, so it becomes sane to manage across multiple environments and for others to more easily match up their local development user-secrets. I now am going to look into a .env based solution, since I'm used to that from other, non-DotNet work I have done. Thanks!

[@timrobertson8242]

I will prefer the use of environment variables for secrets when deploying in Docker Containers (my next frontier) and it seems vital, changing an app Settings file inside of a container (or putting the secret in the image) is really not going to lead to anything particularly secure.

[@DarVilZ]

I've been using user secrets for the past year, it's annoying cause it's difficult to keep track what's in there among different devs, the way you showed will be much more explicit. Thanks!

[@EldonElledge]

I think from a local/Dev environment, it is safe to keep the setting in App.settings. I don't see an issue with committing them to the repo. For other environments, I rely on Azure Vault. I think this is one of those things that we tend to overcomplicate. Outside of a few out of the norm situations.

[@kevinlloyd9507]

Why not just gitignore the appsettings.Development.json? I've done that in the past. But mostly, on private repos we just commit the Dev settings. I do agree, user secrets is kind of abstracted away and clunky to get set up.

[@thomas_pettersen]

Same here. Always gitignore the appsettings.Development-file. I liked the concept of the .env-file. Should be possible to be used in docker as well.

[@rustamhajiyev]

Because with env file you also get a possibility to comment out / swap values, sometimes it's indeed very handy.

[@kevinlloyd9507]

@@rustamhajiyev I've always been able to comment out JSON in appsettings files.

[@user-yr1uq1qe6y]

​@rustamhajiyev I comment out lines of appsettings json config files daily with no issue.

[@awaisshabir9169]

Great idea but bit confusing for different environments . How to set it up with different environment ?

[@simonchester263]

Really interesting. The simplicity of DotEnv over user secrets is attractive. We've recently started using the dotnet user-jwts tool, which seems to have a reliance on the user-secrets infrastructure to manage the key that the JWTs are signed with. I wonder if it could be tweaked to work with DotEnv.

[@rd_45]

Why do you have small audience in youtube.. You work is so great..

[@swildermuth]

I started late. They'll find me eventually.

[@DannyHille]

@swildermuth - I just found your channel. Im another veteran, I have been a professional (payed to do my hobby) developer for 28 years, I like the pace and the discussions in your videos. I'll be sure to send a link to your channel to my friends, keep up the good job!

[@johncerpa3782]

Where do I keep the actual .env if not in source control? So other developers can use them too

[@finnurhrafn]

If you mean actual as a production environment then the actual values should be stored in Azure Key Vault or environment values.

[@Rein______]

Only the example file will be in git, thats the whole point

[@cuachristine]

The problem with this approach is that you are now having to replace values in the .env file whenever u deploy it to a different environment (dev/test/staging/prod). To be fair, I don't have a better solution, just not sure that this is the panacea.

[@ShadoFXPerino]

How about instead of committing Program.cs, set that in gitignore and instead commit a "Program.cs.sample" file. Then you can have complex types, type safety, comments, DI, etc. all at your fingertips.

[@swildermuth]

I can't tell if this is sarcasm or that I don't get the point.

[@ShadoFXPerino]

@@swildermuth Not sarcasm. What are you confused about?

[@ShadoFXPerino]

You just leave blanks where you hardcode your connectionstrings in your Program.cs, rename that file to Program.cs.sample, then commit that. When making a local setup you copy the Program.cs.sample into a new Program.cs file and fill in the blanks, and don't commit the new Program.cs.

[@pilotboba]

@@ShadoFXPerino I don't think we want to hardcode configuration in the program. That's the whole point of configuration. A way to change behavior without changing code.

[@ShadoFXPerino]

@@pilotboba The Program.cs would not be committed to Github, so there's none of the traditional issues with hardcoding configs. Whether the file ends in cs, json, or config doesn't matter. What matters is how the file is created and who has access to it.