I am working with an Asp.Net core application. I have the configuration to disable adaptive sampling of Application Insights in appsettings.json file, as below,
"ApplicationInsights": {
"InstrumentationKey": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"EnableAdaptiveSampling": false
}
And in the Startup.cs, I register the dependency of Application Insights using,
services.AddApplicationInsightsTelemetry();
My understanding is that, with these changes in place, the above mentioned section from appsettings.json configures the instrumentation key and disables adaptive sampling.
Is my understanding correct or is it mandatory to apply these configurations in Startup.cs using ApplicationInsightsServiceOptions to actually disable adaptive sampling in Application Insights telemetry?
Also, with Azure Functions, I have the following configuration in place,
"logging": {
"logLevel": {
"Application_Name": "Information"
},
"applicationInsights": {
"samplingSettings": {
"isEnabled": false
}
}
}
I came through many blogs, that says, these host.json settings are enough for Azure Functions to disable adaptive sampling.
Is this correct?
Related
Although initially enabled, after every firebase deploy --only:functions id/refresh token settings are all disabled:
One has to manually re-enable each time which is super frustrating!
Perhaps this is because a deployment might change the blocking functions (particularly true when transpiling from typescript, etc.).
Is there a way to make these settings "sticky" across deployments?
Alternative suggestion for the world-class firebase team:
Add a new field to firebase.json:
"authentication": { "blockingFunctions": { "refreshToken": true, ...etc } }
Add a checkbox to the configuration UI something like [X] Allow application to manage these settings which, if checked, causes the firebase.json settings to take effect.
I am using microsoft.Identity.Web package on my .netcore API project which calls Graph API to get the directory objects of the user.
In the appsettings file the downstream api settings are provided as below,
"DownstreamApi": {
"BaseUrl": "https://graph.microsoft.com/v1.0",
"Scopes": "Directory.Read.All"
},
The relevant permission(Directory.Read.All) is setup in the app registration.
But even if I leave the "Scope" parameter blank the API is giving me the directory objects.
So if the settings is of the format below it still works. Then what is the need of this scope parameter?
"DownstreamApi": {
"BaseUrl": "https://graph.microsoft.com/v1.0",
"Scopes": ""
},
The scope claim might not had reflected in the token and so you might not seeing any difference with scope assigned.
user_impersonation is the default delegated permission /scope that exists initially for every Web app or API in Azure AD.
Please make sure to add the required delegated permissions or application permission in portal.And grant consent if required.
In your case add directory.read.all Application permission
ex:I added user.read
Appsettings:
"DownstreamApi": {
"BaseUrl": "https://graph.microsoft.com/v1.0",
"Scopes": "user.read"
},
In startUp.cs
Public void ConfigureServices(IServiceCollection services)
{
string[] initialScopes = Configuration.GetValue<string>("DownstreamApi:Scopes")?.Split(' ');
services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(Configuration)
// acquire a token to call a protected web API
.EnableTokenAcquisitionToCallDownstreamApi(initialScopes)
.AddMicrosoftGraph(Configuration.GetSection("DownstreamApi"))
.AddInMemoryTokenCaches();
//
//othercode
...
}
And in controller we need to specify scopes and send to request headers to get access token for required scopes.
References:
call Microsoft Graph | Microsoft Docs
(OR) active-directory-aspnetcore-webapp-openidconnect-v2 (github.com)
How can I create a new Azure App Registration without the user_impersonation OAuth2Permission? - Stack Overflow
If client_credentials is the grant type you may need to use https://graph.microsoft.com/.default for scope in the application settings which will give you the permissions defined for your app.
"DownstreamApi": {
"BaseUrl": "https://graph.microsoft.com/v1.0",
"Scopes": "https://graph.microsoft.com/.default"
}
Try to use /token endpoint in request and not common
Please see:
ASP.NET Core - Call Graph API Using Azure Ad Access Token - Stack Overflow-Reference
Documentation for .net core web jobs suggests that this:
[Disable("messages.disabled")]
public async Task ExecuteAsync(..
should lookup "messages.disabled" in the configuration file and, if set to 1 or True (case insensitive) then it will not run the webjob. This does not appear to be the case.
My app settings are:
{
"AppSettings": {
"messages.disabled": "true"
{
}
but this appears to be ignored and my webjob runs regardless. I've tried "true", "True", "1" and placing the setting in the root of the JSON app setting file.
The code compiles file but does not appear to work as expected. I'm using .net core 2.1, Microsoft.Azure.WebJobs 3.0.14
What am I doing wrong?
Working on some suggestions by #GeorgeChen I think there is a bug in the Disable handling for azure web jobs.
If you add the disable attribute to anything other than appSettings.json then it is ignored. This is impractical as, in the majority of case, you do not want to publish these settings to Azure which invariably appSettings.json is - they are more useful when running locally/debugging so you can turn off message handlers for those subscriptions you are not interested in.
A workaround that appears to work is in your webjob program.cs/startup routine, build your IConfigurationRoot as usual. Typically, this build will pull in from appSettings.config, appSettings.Development.config and appSettings.local.config and merge the results.
You can then pull out of this the disable settings you need from the appropriate level for you environment.
Next, set an Environment variable. This then appears to be picked up by the disable attribute.
var environment = GetEnvironment();
var cfg = new ConfigurationBuilder()
.SetBasePath(Environment.CurrentDirectory)
.AddJsonFile("appsettings.json", false, true)
.AddJsonFile($"appsettings.{environment}.json", true)
.AddJsonFile("appsettings.local.json", true)
.AddEnvironmentVariables()
.Build();
Environment.SetEnvironmentVariable("messages.examplex.disabled", cfg.GetValue<string>("messages.examplex.disabled"));
The Web job method signature:
[Disable("messages.examplex.disabled")]
public async Task ExecuteAsync([ServiceBusTrigger("examplex", "subscribertest")]Message msg)
Firstly about the Disable attribute, after using it in the function method, you should set the app setting in the appsettings.json file, the format would be like below. And remember set the CopyToOutputDirectory property to Copy always or Copy if newer.
appsettings.json:
{
"AzureWebJobsStorage": "storage account connection string",
"Disable": true
}
The other thing is you could use another setting to disable function. You could set "AzureWebJobs.YourFunctionName.Disabled": "true" to disable your function.
I am following introduction to single page authentication tutorial from Microsoft.
This tutorial uses IdentityServerJwt authentication
services.AddAuthentication()
.AddIdentityServerJwt();
I haven't tested yet but as the tutorial says this application works fine in the local environment without doing any configuration for JSON web tokens.
this is how appsettings.Development.json file looks like:
"IdentityServer": {
"Key": {
"Type": "Development"
}
}
On deploy to production section it shows how to configure azure web service, add certificate to azure and app.settings.json file for that configuration.
app.settings.json:
"IdentityServer": {
"Key": {
"Type": "Store",
"StoreName": "My",
"StoreLocation": "CurrentUser",
"Name": "CN=MyApplication"
}
}
So my question is how can I configure my Linux server(ubuntu), how can I add the certificate to validate JSON web tokens and how should I configure my app.settings.json file for my Linux environment. I haven't seen any tutorial which shows that step by step.
Hello I am new to Alexa Skill Kit deployment using ask-cli. I just want to know if there are any deployment practices in place where we have different configurations i.e skills.json and .ask/config
For example, I have a repository some-alexa-skill with 2 branches: staging and production.
staging has this configuration for the skills.json
{
"skillManifest": {
"publishingInformation": {
"locales": {
"en-US": {
"name": "staging"
}
},
"isAvailableWorldwide": true,
"distributionCountries": []
},
"apis": {
"custom": {
"endpoint": {
"uri": "staging",
"sourceDir": "lambda/custom"
}
}
},
"manifestVersion": "1.0"
}
}
while production has this:
{
"skillManifest": {
"publishingInformation": {
"locales": {
"en-US": {
"name": "production"
}
},
"isAvailableWorldwide": true,
"distributionCountries": []
},
"apis": {
"custom": {
"endpoint": {
"uri": "production",
"sourceDir": "lambda/custom"
}
}
},
"manifestVersion": "1.0"
}
}
As I can observe skill.json should be "ignored" in the git respository since it will be replaced whenever merges occur during "release to production". I'm thinking of just ignoring skills.json and just change it when I want to deploy. But I am also considering the ability to allow others to deploy it in their own machines.
Any suggestions on how should I approach this using ask-cli?
Using the API should allow you to control your source and target destinations however you like. Using "profiles" will allow you to keep separate sets of credentials also.
There are 2 different levels of control when using the ask-cli. One is high level, and simplifies creating, cloning, and updating skills. These use the format:
"ask new ..." or "ask clone" to create or copy an existing skill
"ask deploy ..." to update parts or all of the skill.
A lower level API is available that allows more specific control. These use the format "ask api ..." and allow you to specify for example the specific file to upload/download to/from. I've found these better for projects with staging, develop, testing branches, etc.
In all of the ask commands, you can provide a profile that specifies the credentials for the Alexa developer account and the AWS account for the Lambda. Use the "ask init" to set these up. I keep separate profiles for:
my home/hobby projects using my personal accounts
my work related development/debugging
my work client projects accessible by our testers and clients.
The Amazon doc is pretty well written, and explains how to use the ask-cli. It just doesn't go into why you would use multiple profiles, etc.
I hope this helps. Start with the Amazon ask-cli quick start then follow the links to the reference documentation.
One thing to be careful about is to make sure that you are using the latest ask-cli download. As of today it is 1.0.0-beta.4. You can use the "ask -v" command to display your installed version. There were problems with the deploy command in the earlier 1.0.0-beta.1 version.