How do I use a "config file" in custom policies? Like appsetting.json in ASP.Net Core.
Things to configure
TenantId
<LoadUri> for customizing the UI
Background: we have multiple B2C tenants for each environment (Local, Dev, QA, Prod, etc.). We need to promote the custom policies from Local -> Dev -> .... As it stands now, we have to modify the policies when promoting.
I'm hoping there is something like pulling Keys from the B2C app.
There is currently nothing like the Policy Keys to enable environment to environment variable substitution for TenantId, LoadUri etc. in the Azure Portal.
Some potential approaches:
1) SlowCheetah is a Visual Studio 2015/17 tool that allows transformations to be made on XML files. You can utilize this to create an XML transformation file for each B2C policy and environment you have.
For example, you create a UAT transformation file for your B2C_1A_SignIn policy and configure all the variables you need. You then select UAT as the output environment and press F5 to build. This will output a transformed file to your applications bin folder. You will now have all the correct values for UAT, which you can upload to the Azure Portal.
2) Replace Tokens from Visual Studio Team Services Build and Release. This approach allows you to set all your variables as tokens in your policies. You would then initialize a build and release through VSTS and all your defined tokens will be replaced. This approach does require access to VSTS and the setup of code management, build and release. You would also need an output of the build files, e.g. a storage table or file directory on a server.
3) VSTS Build & Release: File transforms and variable substitution reference.
If you are using Visual Studio Code, the Azure AD B2C extension can do this for you using an appsettings.json file.
Here is a quote from the extension page in the Policy Settings section:
When you execute the B2C Policy build command, the VS Code extension finds and replaces the values of your settings with the ones configured in the policy file, and creates a directory that contains all of your policy files (after the replacement).
The VS Code extension does support this. You can add as many settings under PolicySettings as you would like to.
{
"Environments": [
{
"Name": "...",
"Production": true,
"Tenant": "...",
"PolicySettings": {
"ProxyIdentityExperienceFrameworkId": "...",
"LoadUri": "https://myhosted/template",
"somekey" : "some value"
}
}
]
}
You reference it using {Setting:LoadUri-signuporsignin}, do not include PolicySettings. Extensions description
Related
How can I change the appsettings on the preview environemnts that are generated by the Azure Static Web Apps CI/CD Github Action for each pull request?
I can go to the portal, navigate to the generated environment and change its appsettings. Doing this manually for each new pull request is error prone and will become tedious really fast.
I couldn't find any reference to this in the Build Configuration For Azure Static Webapps docs so I'm assuming it can't be configured that way.
I also couldn't find any reference to SWA environments in the CLI docs.
I looked into deployment environments but it looks like this is some other kind of deployment environment as it keeps mentioning devcenter.
In Azure Portal, While Creating Static Web App, after providing the GitHub Repo and Branch details, we will get an option to preview the Workflow file.
I can go to the portal, navigate to the generated environment and change its appsettings
Yes, In Configuration Section we have an option to add the App settings. But it is a manual work, which is not advised to follow.
Once we click on Review + create and create the Static Web App, a new folder with name .github/workflows will be created in the GitHub Repository.
It contains the same workflow file (preview file), which we saw while creating the Static WebApp in Azure Portal.
We can edit the Workflow manually.
To update the appsettings/configurations in the workflow, we can specify the steps in the existing workflow file.
We can use either Powershell/Azure CLI commands to update the Appsettings.
az staticwebapp appsettings set --name YourStaticWebAppname --setting-names "message=HelloEveryOne"
***Sample code for Updating App settings: ***
Before Build and deploystep in Workflow, add the below steps.
- name: Build And Deploy
- run : Your Update appsettings Script
To edit the Workflow file, click on the .github/workflow => .yml file
References taken from MSDoc 1 and 2.
Update
As per the discussion in GitHub, adding appsettings to the preview environment is not currently supported in the default Azure Static Web Apps CI/CD.
Setting appsettings on a specific environment is not currently supported in the Azure Static Web apps CI/CD nor by the Azure CLI.
There is a discussion in GitHub about it.
I have so far used the appsettings.{environment}.json files to keep application level configuration settings. Now I encounter this tab in Azure Portal for an App Service.
What is the difference between using the appsettings.json files and "Application Settings" Tab in the Azure Portal? And which one to use When?
difference between using the appsettings.json files and "Application Settings" Tab in the Azure Portal? And which one to use When?
If you are using more than one environment like Production, Staging and Development for your application. You need specific Environment appsettings i.e., appsettings.{environment}.json.
Or if you don't want to use any specific environment. In this case you are using only production (Default) Environment you can use appsettings.json file.
Few reasons to use Azure Application Settings -
1st - Let's assume that in order to avoid leaking configurations in appsettings.json, you aren't committing it to your repo. But you also deploy your web app on Azure AppServices. In this situation Application Settings tab can help you to configure your configurations directly and then Azure will auto create appsettings.json by reading those values.
2nd - This time we are committing appsettings.json and deployed web app on Azure. We also have a property as
{
"Users": {
"CanAccessApp": [ "abc#gmail.com", "test#gmail.com" ],
"CanAccessHangfire": [ "abc#gmail.com", "test#gmail.com" ],
"CanAccessLog": [ "abc#gmail.com", "test#gmail.com" ]
}
}
Now, I also want one more user to be able to access logs. How you will do it? Generally, update in your appsettings.json and redeploy.
Or you can create similar property in Application Settings by
Users:CanAccessLog:0 -> vic#gmail.com
Users:CanAccessLog:1 -> abc#gmail.com
Users:CanAccessLog:2 -> test#gmail.com
and so on where 0,1,2 are indexes of the array (Azure style). This one will help us to test quickly without redeploying or modifying appsettings.json.
I have an ASP.NET MVC app deployed to Microsoft Azure App Service and am having some trouble with the appSettings and connectionStrings values.
I have some values set in the web.config and some values overriding them in the Application Settings tab of the App Service. I want to quickly and easily view the final values to check that the settings are being picked up correctly.
How can I do this?
Note: I've tried using az webapp config appsettings list but this only seems to bring back what is configured in the Application Settings of the App Service and not the merged results of combining with web.config.
No Azure API will return values that include settings that come from your web.config file.
The only way to get this is to ask the config system within your own runtime. e.g. Use code along these lines:
foreach (string name in ConfigurationManager.AppSettings)
{
string val = ConfigurationManager.AppSettings[name];
...
}
foreach (ConnectionStringSettings settings in ConfigurationManager.ConnectionStrings)
{
string connStr = settings.ConnectionString;
string provider = settings.ProviderName;
...
}
This will give you the effective values that are applied to your app.
You may also use the following blades in Azure Portal (under Development Tools section):
Console
In order to see the file, you may use type command, e.g.:
type web.config
Advanced Tools
This points to the Kudu service.
You may see files deployed when navigating to Debug Console > Choose either CMD or PowerShell. Then navigate to your config directory (e.g. site/wwwroot) and choose to either download or edit file.
App Service Editor
App Service Editor is a relatively new tool in Azure toolset. Default view is a list of files, so you can browse all hosted files, including configuration ones.
You can view all of your runtime appSettings, connection strings and environment variables (and more..) using azure KUDU SCM. if your application address is "https://app_name.azurewebsites.net" you can access it in the address "https://app_name.scm.azurewebsites.net" or from azure portal
With kudo REST API, you can get the settings, delete or post them in this address https://app_name.scm.azurewebsites.net/api/settings
kudo wiki
I have tried adding DefaultConnection from my appsettings.json file to Azure's Application Settings but Azure will not override the connection string.
Any article or blog I can find states that all I should need to do is add the connection string name as it states in the appsettings.json file and Azure should do the rest (e.g. https://tehremo.wordpress.com/2016/10/07/override-connection-strings-app-settings-in-asp-net-core-and-azure-app-service/) however when the application is published it is using my local connection string.
My Startup.cs file looks like the following:
NOTE: I am publishing using VSTS continuous delivery with "Deploy Azure App Service" release task.
I just had a similar problem (the problem was with PostgreSQL connection string type, I had to change it to custom) and now it works for me, so these are the pieces:
This is my appsettings.json file. I have a value for 'Psql' set in my appsettings.Development.json, but in the appsettings.json it is left empty.
These are the settings which are set in the Azure portal. Please note, that there are two ways to override the connection string.
This is the part of my Startup.cs file. Pay attention to the order of how the settings are applied in the Startup constructor and the way I get the connection string in the ConfigureServices method (GetConnectionString is a standard extension method).
Additional info from my comments below:
Azure GUI (Connection strings, Application settings) uses environment variables internally, so the appsettings.json will stay the same.
If there is a need for an appsettings.json's value to be overwritten during VSTS release activity (before it will be published to Azure), Colin's ALM Corner Build & Release Tools can be used. Here are the links to Colin's ALM Corner Build & Release Tools and tutorial.
Thanks #pasul, your help was much appreciated and helped me find an alternative solution. In order to deploy using VSTS task and replace application settings, you will need to add variables to the release task and pass into the task the json file in question for variable substitution.
When in "Deploy Azure App Service" release task you should see a "File Transforms and Variable Substitution" section. In here you will supply the path to the json file you want to swap variable values.
Then you will need to click on the options button on the release environment. You will see an option to configure variables in the pop out menu.
From here you can add the json property you want to modify as a variable. In my case the connection string. Which will look like the following:
"ConnectionStrings.DefaultConnection"
Then just put in your connection string value. VSTS will then swap out these values for you when deploying.
I see several examples of Azure Resource Manager templates, referencing artifacts directly in Git Hub.
As in the following example, taken from this quick start template:
"modulesUrl": {
"type": "string",
"defaultValue": "https://github.com/Azure/azure-quickstart-templates/raw/master/dsc-extension-azure-automation-pullserver/UpdateLCMforAAPull.zip",
"metadata": {
"description": "URL for the DSC configuration package. NOTE: Can be a Github url(raw) to the zip file (this is the default value)"
}
As an orgnaisation, we can't use free Git Hub as code is public and as we pay for VSTS already... At the moment, we have to upload artifacts to Azure Storage Accounts using the VSTS build task Azure Resource Group Deployment task and reference them from there. It would be nice if we could remove this step.
So, is there a way to reference artifacts directly from a VSTS repository in a similar way to Git Hub? I assume the URI would require some form of authentication, such as a PAT token.
All I can find is this, but I think it is referring to packages. I don't need to create packages for ARM templates and DSC configurations.
There is a task called Azure Resource Group Deployment Task, we use this to deploy the ARM template.
According to you sample template, it's using publicly accessible http/https URLs in GitHub. Afraid this is not accessible via vsts url. In VSTS you need to follow below process (Need to use a SAS Token):
You could provide some extra parameters using the output variables defined in the Azure File Copy Task (storageURI, storageToken). This are needed because in the template we use the _artifactsLocation and _artifactsLocationSasToken parameters to build the storage URL to the files.
More details please refer this blog: Setting up VSTS with ARM Templates