Configure Web App settings
Configure Application Settings
In App Service, app settings are variables passed as environment variables to the application code. For Linux apps and custom containers, App Service passes app settings to the container using the --env flag to set the environment variable in the container.
Application settings can be accessed by navigating to your app’s management page and selecting Configuration → Application Settings.
For ASP.NET and ASP.NET Core developers, setting app settings in App Service are like setting them in <appSettings> in Web.config or appsettings.json, but the values in App Service override the ones in Web.config or appsettings.json. You can keep development settings (for example, local MySQL password) in Web.config or appsettings.json, but production secrets (for example, Azure MySQL database password) safe in App Service. The same code uses your development settings when you debug locally, and it uses your production secrets when deployed to Azure.
App settings are always encrypted when stored (encrypted-at-rest).
Configure General Settings
In the Configuration > General settings section you can configure some common settings for your app. Some settings require you to scale up to higher pricing tiers.
- Stack settings: The software stack to run the app, including the language and SDK versions. For Linux apps and custom container apps, you can also set an optional start-up command or file.
- Platform settings: Lets you configure settings for the hosting platform, including:
- Bitness: 32-bit or 64-bit.
- WebSocket protocol: For ASP.NET SignalR or socket.io, for example.
- Always On: Keep the app loaded even when there’s no traffic. By default, Always On is not enabled and the app is unloaded after 20 minutes without any incoming requests. It’s required for continuous WebJobs or for WebJobs that are triggered using a CRON expression.
- Managed pipeline version: The IIS pipeline mode. Set it to Classic if you have a legacy app that requires an older version of IIS.
- HTTP version: Set to 2.0 to enable support for HTTPS/2 protocol.
- ARR affinity: In a multi-instance deployment, ensure that the client is routed to the same instance for the life of the session. You can set this option to Off for stateless applications.
- Debugging: Enable remote debugging for ASP.NET, ASP.NET Core, or Node.js apps. This option turns off automatically after 48 hours
- Incoming client certificates: require client certificates in mutual authentication. TLS mutual authentication is used to restrict access to your app by enabling different types of authentication for it.
Configure Path Mappings
In the Configuration > Path mappings section you can configure handler mappings, and virtual application and directory mappings. The Path mappings page will display different options based on the OS type.
Windows apps (uncontainerized)
For Windows apps, you can customize the IIS handler mappings and virtual applications and directories. Handler mappings let you add custom script processors to handle requests for specific file extensions. To add a custom handler, select New handler. Configure the handler as follows:
- Extension: The file extension you want to handle, such as *.php or handler.fcgi.
- Script processor: The absolute path of the script processor. Requests to files that match the file extension are processed by the script processor. Use the path
D:\home\site\wwwrootto refer to your app’s root directory. - Arguments: Optional command-line arguments for the script processor.
Each app has the default root path (
/) mapped toD:\home\site\wwwroot, where your code is deployed by default. If your app root is in a different folder, or if your repository has more than one application, you can edit or add virtual applications and directories. You can configure virtual applications and directories by specifying each virtual directory and its corresponding physical path relative to the website root (D:\home). To mark a virtual directory as a web application, clear the Directory check box.
Linux and containerized apps
You can add custom storage for your containerized app. Containerized apps include all Linux apps and also the Windows and Linux custom containers running on App Service. Click New Azure Storage Mount and configure your custom storage as follows:
- Name: The display name.
- Configuration options: Basic or Advanced.
- Storage accounts: The storage account with the container you want.
- Storage type: Azure Blobs or Azure Files. Windows container apps only support Azure Files.
- Storage container: For basic configuration, the container you want.
- Share name: For advanced configuration, the file share name.
- Access key: For advanced configuration, the access key.
- Mount path: The absolute path in your container to mount the custom storage.
Enable diagnostic logging
| Type | Platform | Location | Description |
|---|---|---|---|
| Application logging | Windows, Linux | App Service file system and/or Azure Storage blobs | Logs messages generated by your application code. The messages can be generated by the web framework you choose, or from your application code directly using the standard logging pattern of your language. Each message is assigned one of the following categories: Critical, Error, Warning, Info, Debug, and Trace. |
| Web server logging | Windows | App Service file system or Azure Storage blobs | Raw HTTP request data in the W3C extended log file format. Each log message includes data like the HTTP method, resource URI, client IP, client port, user agent, response code, and so on. |
| Detailed error logging | Windows | App Service file system | Copies of the .htm error pages that would have been sent to the client browser. For security reasons, detailed error pages shouldn’t be sent to clients in production, but App Service can save the error page each time an application error occurs that has HTTP code 400 or greater. |
| Failed request tracing | Windows | App Service file system | Detailed tracing information on failed requests, including a trace of the IIS components used to process the request and the time taken in each component. One folder is generated for each failed request, which contains the XML log file, and the XSL stylesheet to view the log file with. |
| Deployment logging | Windows, Linux | App Service file system | Helps determine why a deployment failed. Deployment logging happens automatically and there are no configurable settings for deployment logging. |
Configure security certificates
Private certificate requirements
The free App Service managed certificate and the App Service certificate already satisfy the requirements of App Service. If you want to use a private certificate in App Service, your certificate must meet the following requirements:
- Exported as a password-protected PFX file, encrypted using triple DES.
- Contains private key at least 2048 bits long
- Contains all intermediate certificates in the certificate chain To secure a custom domain in a TLS binding, the certificate has additional requirements:
- Contains an Extended Key Usage for server authentication (OID = 1.3.6.1.5.5.7.3.1)
- Signed by a trusted certificate authority
Creating a free managed certificate
To create custom TLS/SSL bindings or enable client certificates for your App Service app, your App Service plan must be in the Basic, Standard, Premium, or Isolated tier. Custom SSL is not supported in the F1 or D1 tier. The free App Service managed certificate is a turn-key solution for securing your custom DNS name in App Service. It’s a TLS/SSL server certificate that’s fully managed by App Service and renewed continuously and automatically in six-month increments, 45 days before expiration. You create the certificate and bind it to a custom domain, and let App Service do the rest. There are limitations such as no support for wildcard, non-exportable, client certificate by certificate thumbprint, etc.
Import an App Service Certificate
You can import and manage the certificate, and Azure managed the purchase process, verification, AKV maintenance, renewal, and synchronization.
Upload a private certificate
If your certificate authority gives you multiple certificates in the certificate chain, you need to merge the certificates in order. Then you can Export your merged TLS/SSL certificate with the private key that your certificate request was generated with. If you generated your certificate request using OpenSSL, then you have created a private key file. You can then export the certificate to PFX and define an export password that you’ll use when uploading the TLS/SSL certificate to App Service.
Enforce HTTPS
By default, anyone can still access your app using HTTP. You can redirect all HTTP requests to the HTTPS port by navigating to your app page and, in the left navigation, select TLS/SSL settings. Then, in HTTPS Only, select On.
Manage app features
- Feature flag: A feature flag is a variable with a binary state of on or off. The feature flag also has an associated code block. The state of the feature flag triggers whether the code block runs or not.
- Feature manager: A feature manager is an application package that handles the lifecycle of all the feature flags in an application. The feature manager typically provides additional functionality, such as caching feature flags and updating their states.
- Filter: A filter is a rule for evaluating the state of a feature flag. A user group, a device or browser type, a geographic location, and a time window are all examples of what a filter can represent. When a feature flag has multiple filters, the filter list is traversed in order until one of the filters determines the feature should be enabled. At that point, the feature flag is on, and any remaining filter results are skipped. If no filter indicates the feature should be enabled, the feature flag is off.