In .NET Framework the web.config could be encrypted to hide the connection strings and any app settings that may contain secrets. While simple to reverse if you have access to the machine it at least protected against any hacks that allowed viewing of the web.config file via the browser.
In .NET 5 we don't have that option. From what I can see it would be possible to set an environment variable to provide the connection string, but as we host multiple Umbraco sites on the same server I can't see a way of setting it per instance.
Does anyone know of a way to run multiple Umbraco 9 instances on a single server without having to leave the connection string in the appsettings.json file?
using the donet user-secret command you can set the secrets on a per project basis.
it doesn't actually offer encypted storage but it does move the values out of the project, and it would require the machine to be comprimised for the values to get out (and if the machine was comprimised, there is a high chance environmental variables would be too).
another way is to prefix environmental values in code. e.g from the docs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Configuration.AddEnvironmentVariables(prefix: "MyCustomPrefix_");
var app = builder.Build();
you would ofcouse have to have a diffrent bit in each project so they pointed to their variables, which isn't ideal, but it does mean you could use the environment settings, to do it.
Sort of in the same vein; I was wondering about something similar. I've ended up using Environment Variables on Azure (within each app) and then locally because I have 20+ sites; rather than using Environment Variables on my local machine I use launchSettings.json and then specify the dev environment details in there.
I did look at the user secret stuff, but was a bit concerned how we could then share details amongst the dev team and cloning a repo would leave you with something that didn't work?! I know technically it's not great storing our dev details within DevOps, but if someone cracks that then I think they're gonna be far more interested in the code and exploiting that than access to a dev DB we can (and often do) write off and start again with.
Then I was faced with an issue with Azure File Providers (aside from my other issues about the CDN not appearing to work!) where it appears to be set to look for a certain Environment variable (rather than users telling it what to look for) which meant you couldn't just pop the Env Variables on your dev machine once you had more than one site. launchSettings gets around that, but setting the Env Variables in there.
I looked at the User Secret thing but most documentation I've read suggests that is not meant for Production use. Our use case is agency shared hosting.
Kevin's suggestion for prefixing sounds promising though - if that can be used to prefix the Umbraco connection string name. I'll test it out as soon as I get a chance!
Connection string obfuscation on shared server
In .NET Framework the web.config could be encrypted to hide the connection strings and any app settings that may contain secrets. While simple to reverse if you have access to the machine it at least protected against any hacks that allowed viewing of the web.config file via the browser.
In .NET 5 we don't have that option. From what I can see it would be possible to set an environment variable to provide the connection string, but as we host multiple Umbraco sites on the same server I can't see a way of setting it per instance.
Does anyone know of a way to run multiple Umbraco 9 instances on a single server without having to leave the connection string in the appsettings.json file?
Hi Chris
I think you can do something via user secrets (see https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-6.0&tabs=windows)
using the
donet user-secretcommand you can set the secrets on a per project basis.it doesn't actually offer encypted storage but it does move the values out of the project, and it would require the machine to be comprimised for the values to get out (and if the machine was comprimised, there is a high chance environmental variables would be too).
another way is to prefix environmental values in code. e.g from the docs
you would ofcouse have to have a diffrent bit in each project so they pointed to their variables, which isn't ideal, but it does mean you could use the environment settings, to do it.
Hey Kevin,
This works for me. I've added the prefixed environment variables into the builder and confirmed that the connection string is overridden.
Thanks so much for your help!
Sort of in the same vein; I was wondering about something similar. I've ended up using Environment Variables on Azure (within each app) and then locally because I have 20+ sites; rather than using Environment Variables on my local machine I use launchSettings.json and then specify the dev environment details in there.
I did look at the user secret stuff, but was a bit concerned how we could then share details amongst the dev team and cloning a repo would leave you with something that didn't work?! I know technically it's not great storing our dev details within DevOps, but if someone cracks that then I think they're gonna be far more interested in the code and exploiting that than access to a dev DB we can (and often do) write off and start again with.
Then I was faced with an issue with Azure File Providers (aside from my other issues about the CDN not appearing to work!) where it appears to be set to look for a certain Environment variable (rather than users telling it what to look for) which meant you couldn't just pop the Env Variables on your dev machine once you had more than one site. launchSettings gets around that, but setting the Env Variables in there.
I looked at the User Secret thing but most documentation I've read suggests that is not meant for Production use. Our use case is agency shared hosting.
Kevin's suggestion for prefixing sounds promising though - if that can be used to prefix the Umbraco connection string name. I'll test it out as soon as I get a chance!
is working on a reply...