You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
title: "What's new in Azure Active Directory business-to-customer (B2C)"
3
3
description: "New and updated documentation for the Azure Active Directory business-to-customer (B2C)."
4
-
ms.date: 07/31/2024
4
+
ms.date: 09/11/2024
5
5
ms.service: active-directory
6
6
ms.subservice: B2C
7
7
ms.topic: whats-new
@@ -19,6 +19,14 @@ manager: CelesteDG
19
19
20
20
Welcome to what's new in Azure Active Directory B2C documentation. This article lists new docs that have been added and those that have had significant updates in the last three months. To learn what's new with the B2C service, see [What's new in Microsoft Entra ID](../active-directory/fundamentals/whats-new.md), [Azure AD B2C developer release notes](custom-policy-developer-notes.md) and [What's new in Microsoft Entra External ID](/entra/external-id/whats-new-docs).
21
21
22
+
## August 2024
23
+
24
+
This month, we changed Twitter to X in numerous articles and code samples.
25
+
26
+
### Updated articles
27
+
28
+
-[Tutorial: Configure Keyless with Azure Active Directory B2C](partner-keyless.md) - Editorial updates
29
+
22
30
## July 2024
23
31
24
32
### Updated articles
@@ -31,17 +39,4 @@ Welcome to what's new in Azure Active Directory B2C documentation. This article
31
39
### Updated articles
32
40
33
41
-[Define an OAuth2 custom error technical profile in an Azure Active Directory B2C custom policy](oauth2-error-technical-profile.md) - Error code updates
34
-
-[Configure authentication in a sample Python web app by using Azure AD B2C](configure-authentication-sample-python-web-app.md) - Python version update
35
-
36
-
37
-
## May 2024
38
-
39
-
### New articles
40
-
41
-
-[Configure Transmit Security with Azure Active Directory B2C for risk detection and prevention](partner-transmit-security.md)
42
-
43
-
### Updated articles
44
-
45
-
-[Set up sign-up and sign-in with a LinkedIn account using Azure Active Directory B2C](identity-provider-linkedin.md) - Updated LinkedIn instructions
-[Configure authentication in a sample Python web app by using Azure AD B2C](configure-authentication-sample-python-web-app.md) - Python version updates
title: Route traffic using parameter based path selection in portal - Azure Application Gateway
3
+
description: Learn how to use the Azure portal to configure an Azure Application Gateway to choose the backend pool based on the value of a header, part of URL, or query string in the request.
4
+
services: application-gateway
5
+
author: greg-lindsay
6
+
ms.service: azure-application-gateway
7
+
ms.topic: how-to
8
+
ms.date: 09/10/2024
9
+
ms.author: greglin
10
+
ms.custom: mvc
11
+
---
12
+
# Perform parameter based path selection with Azure Application Gateway - Azure portal
13
+
14
+
This article describes how to use the Azure portal to configure an [Application Gateway v2 SKU](./application-gateway-autoscaling-zone-redundant.md) instance to perform parameter based path selection by combining the capabilities of URL Rewrite with path-based routing.
15
+
16
+
If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.
17
+
18
+
## Before you begin
19
+
20
+
You need to have an Application Gateway v2 SKU instance to complete the steps in this article. URL rewrite and rewriting headers aren't supported in the v1 SKU. If you don't have the v2 SKU, create an [Application Gateway v2 SKU](./tutorial-autoscale-ps.md) instance before you begin.
21
+
22
+
23
+
## Sign in to Azure
24
+
25
+
Sign in to the [Azure portal](https://portal.azure.com/) with your Azure account.
26
+
27
+
## Configure parameter based path selection
28
+
29
+
For this example, you have a shopping website and the product category is passed as query string in the URL, and you want to route the request to backend based on the query string, then:
30
+
31
+
**Step 1:** Create a path-map as shown in the following image:
32
+
33
+
:::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-1.png" alt-text="A screenshot of URL rewrite scenario 1-1.":::
34
+
35
+
**Step 2 (a):** Create a rewrite set which has 3 rewrite rules:
36
+
37
+
* The first rule has a condition that checks the *query_string* variable for *category=shoes* and has an action that rewrites the URL path to /*listing1* and has **Reevaluate path map** enabled
38
+
39
+
* The second rule has a condition that checks the *query_string* variable for *category=bags* and has an action that rewrites the URL path to /*listing2* and has **Reevaluate path map** enabled
40
+
41
+
* The third rule has a condition that checks the *query_string* variable for *category=accessories* and has an action that rewrites the URL path to /*listing3* and has **Reevaluate path map** enabled
42
+
43
+
:::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-2.png" alt-text="A screenshot of URL rewrite scenario 1-2.":::
44
+
45
+
46
+
**Step 2 (b):** Associate this rewrite set with the default path of the previous path-based rule:
47
+
48
+
:::image type="content" source="./media/rewrite-http-headers-url/url-scenario1-3.png" alt-text="A screenshot of URL rewrite scenario 1-3.":::
49
+
50
+
If the user requests *contoso.com/listing?category=any*, then it's matched with the default path since none of the path patterns in the path map (/listing1, /listing2, /listing3) are matched. Since you associated the previous rewrite set with this path, this rewrite set is evaluated. Because the query string doesn't match the condition in any of the 3 rewrite rules in this rewrite set, no rewrite action takes place. Therefore, the request is routed unchanged to the backend associated with the default path (which is *GenericList*).
51
+
52
+
If the user requests *contoso.com/listing?category=shoes*, then the default path is matched. However, in this case, the condition in the first rule matches. Therefore, the action associated with the condition is executed, which rewrites the URL path to /*listing1* and reevaluates the path-map. When the path-map is reevaluated, the request matches the path associated with pattern */listing1* and the request is routed to the backend associated with this pattern (ShoesListBackendPool).
53
+
54
+
> [!NOTE]
55
+
> This scenario can be extended to any header or cookie value, URL path, query string or server variables based on the conditions defined and essentially enables you to route requests based on those conditions.
56
+
57
+
## Next steps
58
+
59
+
To learn more about how to set up some common use cases, see [common header rewrite scenarios](./rewrite-http-headers-url.md).
Copy file name to clipboardExpand all lines: articles/application-gateway/rewrite-http-headers-url.md
+6-26Lines changed: 6 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: This article provides an overview of rewriting HTTP headers and URL
4
4
author: greg-lindsay
5
5
ms.service: azure-application-gateway
6
6
ms.topic: conceptual
7
-
ms.date: 09/06/2024
7
+
ms.date: 09/10/2024
8
8
ms.author: greglin
9
9
---
10
10
@@ -203,7 +203,7 @@ Here are the steps for replacing the hostname:
203
203
1. Create a rewrite rule with a condition that evaluates if the location header in the response contains azurewebsites.net. Enter the pattern `(https?):\/\/.*azurewebsites\.net(.*)$`.
204
204
2. Perform an action to rewrite the location header so that it has the application gateway's hostname. Do this by entering `{http_resp_Location_1}://contoso.com{http_resp_Location_2}` as the header value. Alternatively, you can also use the server variable `host` to set the hostname to match the original request.
205
205
206
-

206
+

207
207
208
208
#### Implement security HTTP headers to prevent vulnerabilities
209
209
@@ -229,34 +229,14 @@ You can evaluate an HTTP request or response header for the presence of a header
229
229
230
230
#### Parameter based path selection
231
231
232
-
To accomplish scenarios where you want to choose the backend pool based on the value of a header, part of the URL, or query string in the request, you can use the combination of URL Rewrite capability and path-based routing. For example, if you have a shopping website and the product category is passed as query string in the URL, and you want to route the request to backend based on the query string, then:
232
+
To accomplish scenarios where you want to choose the backend pool based on the value of a header, part of the URL, or query string in the request, you can use a combination of URL Rewrite capability and path-based routing.
233
233
234
-
**Step1:** Create a path-map as shown in the image below
234
+
To do this, create a rewrite set with a condition that checks for a specific parameter (query string, header, etc.) and then performs an action where it changes the URL path (ensure **Reevaluate path map**is enabled). The rewrite set must then be associated to a path based rule. The path based rule must contain the same URL paths specified in the rewrite set and their corresponding backend pool.
Thus, the rewrite set allows users to check for a specific parameter and assign it a new path, and the path based rule allows users to assign backend pools to those paths. As long as "Reevaluate path map" is enabled, traffic routs based on the path specified in the rewrite set.
237
237
238
-
**Step 2 (a):** Create a rewrite set which has 3 rewrite rules:
238
+
For a use case example using query strings, see [Route traffic using parameter based path selection in portal](parameter-based-path-selection-portal.md).
239
239
240
-
* The first rule has a condition that checks the *query_string* variable for *category=shoes* and has an action that rewrites the URL path to /*listing1* and has **Reevaluate path map** enabled
241
-
242
-
* The second rule has a condition that checks the *query_string* variable for *category=bags* and has an action that rewrites the URL path to /*listing2* and has **Reevaluate path map** enabled
243
-
244
-
* The third rule has a condition that checks the *query_string* variable for *category=accessories* and has an action that rewrites the URL path to /*listing3* and has **Reevaluate path map** enabled
If the user requests *contoso.com/listing?category=any*, then it's matched with the default path since none of the path patterns in the path map (/listing1, /listing2, /listing3) are matched. Since you associated the previous rewrite set with this path, this rewrite set is evaluated. Because the query string won't match the condition in any of the 3 rewrite rules in this rewrite set, no rewrite action takes place. Therefore, the request is routed unchanged to the backend associated with the default path (which is *GenericList*).
255
-
256
-
If the user requests *contoso.com/listing?category=shoes*, then the default path is matched. However, in this case the condition in the first rule matches. Therefore, the action associated with the condition is executed, which rewrites the URL path to /*listing1* and reevaluates the path-map. When the path-map is reevaluated, the request matches the path associated with pattern */listing1* and the request is routed to the backend associated with this pattern (ShoesListBackendPool).
257
-
258
-
> [!NOTE]
259
-
> This scenario can be extended to any header or cookie value, URL path, query string or server variables based on the conditions defined and essentially enables you to route requests based on those conditions.
260
240
261
241
#### Rewrite query string parameters based on the URL
This article covers replication of Azure App Configuration stores. You'll learn about how to create, use and delete a replica in your configuration store.
19
+
This article covers replication of Azure App Configuration stores. You learn about how to create, use, and delete a replica in your configuration store.
20
20
21
21
To learn more about the concept of geo-replication, see [Geo-replication in Azure App Configuration](./concept-geo-replication.md).
22
22
@@ -90,7 +90,7 @@ To delete a replica in the portal, follow the steps below.
90
90
91
91
## Automatic replica discovery
92
92
93
-
The App Configuration providers can automatically discover any additional replicas from a given App Configuration endpoint and attempt to connect to them. This feature allows you to benefit from geo-replication without having to change your code or redeploy your application. This means you can enable geo-replication or add extra replicas even after your application has been deployed.
93
+
The App Configuration providers can automatically discover any replicas from a given App Configuration endpoint and attempt to connect to them. This feature allows you to benefit from geo-replication without having to change your code or redeploy your application. This means you can enable geo-replication or add extra replicas even after your application has been deployed.
94
94
95
95
Automatic replica discovery is enabled by default, but you can refer to the following sample code to disable it (not recommended).
96
96
@@ -147,13 +147,25 @@ spec:
147
147
> [!NOTE]
148
148
> The automatic replica discovery and failover support is available if you use version **1.3.0** or later of [Azure App Configuration Kubernetes Provider](./quickstart-azure-kubernetes-service.md).
149
149
150
+
### [Python](#tab/python)
151
+
152
+
Specify the `replica_discovery_enabled` property when loading the configuration store and set it to `False`.
> The automatic replica discovery support is available if you use version **1.3.0** or later.
161
+
150
162
---
151
163
152
164
## Scale and failover with replicas
153
165
154
166
Each replica you create has its dedicated endpoint. If your application resides in multiple geo-locations, you can update each deployment of your application in a location to connect to the replica closer to that location, which helps minimize the network latency between your application and App Configuration. Since each replica has its separate request quota, this setup also helps the scalability of your application while it grows to a multi-region distributed service.
155
167
156
-
When geo-replication is enabled, and if one replica isn't accessible, you can let your application failover to another replica for improved resiliency. App Configuration providers have built-in failover support through user provided replicas as well as additional automatically discovered replicas. You can provide a list of your replica endpoints in the order of the most preferred to the least preferred endpoint. When the current endpoint isn't accessible, the provider will fail over to a less preferred endpoint, but it will try to connect to the more preferred endpoints from time to time. If all user provided replicas are not accessible, the automatically discovered replicas will be randomly selected and used. When a more preferred endpoint becomes available, the provider will switch to it for future requests.
168
+
When geo-replication is enabled, and if one replica isn't accessible, you can let your application failover to another replica for improved resiliency. App Configuration providers have built-in failover support through user provided replicas and/or additional automatically discovered replicas. You can provide a list of your replica endpoints in the order of the most preferred to the least preferred endpoint. When the current endpoint isn't accessible, the provider will fail over to a less preferred endpoint, but it tries to connect to the more preferred endpoints from time to time. If all user provided replicas aren't accessible, the automatically discovered replicas will be randomly selected and used. When a more preferred endpoint becomes available, the provider will switch to it for future requests.
157
169
158
170
Assuming you have an application using Azure App Configuration, you can update it as the following sample code to take advantage of the failover feature. You can either provide a list of endpoints for Microsoft Entra authentication or a list of connection strings for access key-based authentication.
The Azure App Configuration Kubernetes Provider supports failover with automatically discovered replicas by default, as long as automatic replica discovery is not disabled. It does not support or require user-provided replicas.
242
+
The Azure App Configuration Kubernetes Provider supports failover with automatically discovered replicas by default, as long as automatic replica discovery isn't disabled. It doesn't support or require user-provided replicas.
243
+
244
+
### [Python](#tab/python)
245
+
246
+
The Azure App Configuration Python Provider supports failover with automatically discovered replicas by default, as long as automatic replica discovery isn't disabled. It doesn't support or require user-provided replicas.
0 commit comments