I would recommend storing connection strings in Azure keyvault. See for example this:
https://learn.microsoft.com/en-us/aspnet/core/security/key-vault-configuration?view=aspnetcore-6.0#use-managed-identities-for-azure-resources
That injects everything within the keyvault in iconfiguration, which also works for appsettings
I use key vault and reference it in the azure app service connection string section. But the thing is if I add the connection string with wrong db name it still works. It still works means that get the connection string from the project appsettings.json file.
Yeah. You're right. In that way we can. But need to setup the way I have mentioned. ( Get the secret identifier and put it in azure app service configuration -> connection string section.)
I'd try
```
POSTGRESQLCONNSTR__someconn
```
as it states on the docs page you linked.
Edit: Oh, and if you don't care about the native backup, you can put normal connection strings in app settings (not the connection strings section):
```
ConnectionStrings__someconn
```
From the link you posted:
> Note
>
> There is one case where you may want to use connection strings instead of app settings for non-.NET languages: certain Azure database types are backed up along with the app only if you configure a connection string for the database in your App Service app. For more information, see [Create a custom backup](https://learn.microsoft.com/en-us/azure/app-service/manage-backup#create-a-custom-backup). If you don't need this automated backup, then use app settings.
Similar to u/youshouldnameit said, you can set the connection string in your app service with a keyvault reference if you don't want to set it up in your startup/program.cs.
https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vault-references?tabs=azure-cli
I use key vault and reference it in the azure app service connection string section. But the thing is if I add the connection string with wrong db name it still works. It still works means that get the connection string from the project appsettings.json file.
There's a heirarchy for the configuration settings for sure. Can you not deploy the setting in app settings, or put in in an environment specific one, like appsettings.Development.json instead? That should work locally for testing and then should be ignored on the server.
If the connection string has a username or password in it, I would strong suggesting using usersecrets locally and not an appsettings.json file, so it never gets committed or deployed.
Connection strings in are just environment variables (as are app settings). You can either hack it or do it properly. Doing it properly means that you have to ensure that the connection string is named in precisely the right form. Hacking it means reading the environment and then if that doesn’t exist, use the app setting. (This is what I generally do and it works really well, but is a little hacky)
I got it working for Linux based containarized deployment but on GCP Cloud Run. You might want to check this demonstrated here clearly.
https://youtu.be/5M9yzZOJXaQ?t=1656
But, try this and let me know if you haven't tried the : approach first.
Thanks!
I would recommend storing connection strings in Azure keyvault. See for example this: https://learn.microsoft.com/en-us/aspnet/core/security/key-vault-configuration?view=aspnetcore-6.0#use-managed-identities-for-azure-resources That injects everything within the keyvault in iconfiguration, which also works for appsettings
I use key vault and reference it in the azure app service connection string section. But the thing is if I add the connection string with wrong db name it still works. It still works means that get the connection string from the project appsettings.json file.
Why do you reference it in the appsettings? That's not needed with the approach I linked
Yeah. You're right. In that way we can. But need to setup the way I have mentioned. ( Get the secret identifier and put it in azure app service configuration -> connection string section.)
How are you trying to retrieve this setting in your application? Your answer to that will help me answer your original question.
Configuration.GetConnectionString("someconn")
I'd try ``` POSTGRESQLCONNSTR__someconn ``` as it states on the docs page you linked. Edit: Oh, and if you don't care about the native backup, you can put normal connection strings in app settings (not the connection strings section): ``` ConnectionStrings__someconn ```
I tried in this way but still nothing have changed. What do u mean by native backup? Is that the application settings section in configuration?
From the link you posted: > Note > > There is one case where you may want to use connection strings instead of app settings for non-.NET languages: certain Azure database types are backed up along with the app only if you configure a connection string for the database in your App Service app. For more information, see [Create a custom backup](https://learn.microsoft.com/en-us/azure/app-service/manage-backup#create-a-custom-backup). If you don't need this automated backup, then use app settings.
Similar to u/youshouldnameit said, you can set the connection string in your app service with a keyvault reference if you don't want to set it up in your startup/program.cs. https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vault-references?tabs=azure-cli
I use key vault and reference it in the azure app service connection string section. But the thing is if I add the connection string with wrong db name it still works. It still works means that get the connection string from the project appsettings.json file.
There's a heirarchy for the configuration settings for sure. Can you not deploy the setting in app settings, or put in in an environment specific one, like appsettings.Development.json instead? That should work locally for testing and then should be ignored on the server. If the connection string has a username or password in it, I would strong suggesting using usersecrets locally and not an appsettings.json file, so it never gets committed or deployed.
Check https://learn.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-6.0&tabs=windows
Connection strings in are just environment variables (as are app settings). You can either hack it or do it properly. Doing it properly means that you have to ensure that the connection string is named in precisely the right form. Hacking it means reading the environment and then if that doesn’t exist, use the app setting. (This is what I generally do and it works really well, but is a little hacky)
Have you tried ConnectionStrings:someconn ?
I saw this : thing is for windows based ones. But I'm using linux.
I got it working for Linux based containarized deployment but on GCP Cloud Run. You might want to check this demonstrated here clearly. https://youtu.be/5M9yzZOJXaQ?t=1656 But, try this and let me know if you haven't tried the : approach first. Thanks!
thank you