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
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/localization.md
+5-156Lines changed: 5 additions & 156 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ manager: celestedg
8
8
ms.service: active-directory
9
9
ms.workload: identity
10
10
ms.topic: reference
11
-
ms.date: 03/09/2020
11
+
ms.date: 03/11/2020
12
12
ms.author: mimart
13
13
ms.subservice: B2C
14
14
---
@@ -203,160 +203,9 @@ Under the **BuildingBlocks** element, add the **Localization** element with the
203
203
</Localization>
204
204
```
205
205
206
-
### Provide language-specific strings and collections
206
+
##Next steps
207
207
208
-
Add **LocalizedResources** elements inside the **Localization** element after the close of the **SupportedLanguages** element. You add **LocalizedResources** elements for each page (content definition) and any language you want to support. To customize the unified sign-up or sign-in page, sign-up and multi-factor authentication (MFA) pages for English, Spanish, and France, you add the following **LocalizedResources** elements.
208
+
See the following articles for localization examples:
209
209
210
-
- Unified sign-up or sign-in page, English `<LocalizedResources Id="api.signuporsignin.en">`
211
-
- Unified sign-up or sign-in page, Spanish `<LocalizedResources Id="api.signuporsignin.es">`
212
-
- Unified sign-up or sign-in page, France `<LocalizedResources Id="api.signuporsignin.fr">`
213
-
- Sign-Up, English `<LocalizedResources Id="api.localaccountsignup.en">`
- MFA, France `<LocalizedResources Id="api.phonefactor.fr">`
219
-
220
-
Each **LocalizedResources** element contains all of the required **LocalizedStrings** elements with multiple **LocalizedString** elements and **LocalizedCollections** elements with multiple **LocalizedCollection** elements. The following example adds the sign-up page English localization:
221
-
222
-
Note: This example makes a reference to `Gender` and `City` claim types. To use this example, make sure you define those claims. For more information, see [ClaimsSchema](claimsschema.md).
<LocalizedStringElementType="ClaimType"ElementId="email"StringId="UserHelpText">Please enter your email</LocalizedString>
242
-
<LocalizedStringElementType="ClaimType"ElementId="email"StringId="PatternHelpText">Please enter a valid email address</LocalizedString>
243
-
<LocalizedStringElementType="UxElement"StringId="button_continue">Create new account</LocalizedString>
244
-
<LocalizedStringElementType="ErrorMessage"StringId="UserMessageIfClaimsPrincipalAlreadyExists">The account you are trying to create already exists, please sign-in.</LocalizedString>
<LocalizedStringElementType="ClaimType"ElementId="email"StringId="DisplayName">Dirección de correo electrónico</LocalizedString>
268
-
<LocalizedStringElementType="ClaimType"ElementId="email"StringId="UserHelpText">Dirección de correo electrónico que puede usarse para ponerse en contacto con usted.</LocalizedString>
269
-
<LocalizedStringElementType="ClaimType"ElementId="email"StringId="PatternHelpText">Introduzca una dirección de correo electrónico.</LocalizedString>
<LocalizedStringElementType="ErrorMessage"StringId="UserMessageIfClaimsPrincipalAlreadyExists">Ya existe un usuario con el id. especificado. Elija otro diferente.</LocalizedString>
272
-
</LocalizedStrings>
273
-
</LocalizedResources>
274
-
```
275
-
276
-
### Edit the ContentDefinition for the page
277
-
278
-
For each page that you want to localize, specify the language codes to look for in the **ContentDefinition**.
279
-
280
-
In the following example, English (en) and Spanish (es) custom strings are added to the sign-up page. The **LocalizedResourcesReferenceId** for each **LocalizedResourcesReference** is the same as their locale, but you could use any string as the identifier. For each language and page combination, you point to the corresponding **LocalizedResources** you previously created.
<LocalizedStringElementType="ClaimType"ElementId="email"StringId="UserHelpText">Please enter your email</LocalizedString>
332
-
<LocalizedStringElementType="ClaimType"ElementId="email"StringId="PatternHelpText">Please enter a valid email address</LocalizedString>
333
-
<LocalizedStringElementType="UxElement"StringId="button_continue">Create new account</LocalizedString>
334
-
<LocalizedStringElementType="ErrorMessage"StringId="UserMessageIfClaimsPrincipalAlreadyExists">The account you are trying to create already exists, please sign-in.</LocalizedString>
<LocalizedStringElementType="ClaimType"ElementId="email"StringId="DisplayName">Dirección de correo electrónico</LocalizedString>
353
-
<LocalizedStringElementType="ClaimType"ElementId="email"StringId="UserHelpText">Dirección de correo electrónico que puede usarse para ponerse en contacto con usted.</LocalizedString>
354
-
<LocalizedStringElementType="ClaimType"ElementId="email"StringId="PatternHelpText">Introduzca una dirección de correo electrónico.</LocalizedString>
<LocalizedStringElementType="ErrorMessage"StringId="UserMessageIfClaimsPrincipalAlreadyExists">Ya existe un usuario con el id. especificado. Elija otro diferente.</LocalizedString>
357
-
</LocalizedStrings>
358
-
</LocalizedResources>
359
-
<!-- More localized resources... -->
360
-
</Localization>
361
-
</BuildingBlocks>
362
-
```
210
+
-[Language customization with custom policy in Azure Active Directory B2C](custom-policy-localization.md)
211
+
-[Language customization with user flows in Azure Active Directory B2C](user-flow-language-customization.md)
Copy file name to clipboardExpand all lines: articles/api-management/api-management-cross-domain-policies.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -122,7 +122,7 @@ This example demonstrates how to support pre-flight requests, such as those with
122
122
|cors|Root element.|Yes|N/A|
123
123
|allowed-origins|Contains `origin` elements that describe the allowed origins for cross-domain requests. `allowed-origins` can contain either a single `origin` element that specifies `*` to allow any origin, or one or more `origin` elements that contain a URI.|Yes|N/A|
124
124
|origin|The value can be either `*` to allow all origins, or a URI that specifies a single origin. The URI must include a scheme, host, and port.|Yes|If the port is omitted in a URI, port 80 is used for HTTP and port 443 is used for HTTPS.|
125
-
|allowed-methods|This element is required if methods other than GET or POST are allowed. Contains `method` elements that specify the supported HTTP verbs.|No|If this section is not present, GET and POST are supported.|
125
+
|allowed-methods|This element is required if methods other than GET or POST are allowed. Contains `method` elements that specify the supported HTTP verbs. The value `*` indicates all methods.|No|If this section is not present, GET and POST are supported.|
126
126
|method|Specifies an HTTP verb.|At least one `method` element is required if the `allowed-methods` section is present.|N/A|
127
127
|allowed-headers|This element contains `header` elements specifying names of the headers that can be included in the request.|No|N/A|
128
128
|expose-headers|This element contains `header` elements specifying names of the headers that will be accessible by the client.|No|N/A|
@@ -132,8 +132,8 @@ This example demonstrates how to support pre-flight requests, such as those with
|allow-credentials|The `Access-Control-Allow-Credentials` header in the preflight response will be set to the value of this attribute and affect the client’s ability to submit credentials in cross-domain requests.|No|false|
136
-
|preflight-result-max-age|The `Access-Control-Max-Age` header in the preflight response will be set to the value of this attribute and affect the user agent’s ability to cache pre-flight response.|No|0|
135
+
|allow-credentials|The `Access-Control-Allow-Credentials` header in the preflight response will be set to the value of this attribute and affect the client's ability to submit credentials in cross-domain requests.|No|false|
136
+
|preflight-result-max-age|The `Access-Control-Max-Age` header in the preflight response will be set to the value of this attribute and affect the user agent's ability to cache pre-flight response.|No|0|
137
137
138
138
### Usage
139
139
This policy can be used in the following policy [sections](https://azure.microsoft.com/documentation/articles/api-management-howto-policies/#sections) and [scopes](https://azure.microsoft.com/documentation/articles/api-management-howto-policies/#scopes).
Copy file name to clipboardExpand all lines: articles/api-management/api-management-howto-developer-portal.md
+4-11Lines changed: 4 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -137,19 +137,12 @@ Most configuration changes (for example, VNet, sign-in and product terms) requir
137
137
The interactive console makes a client-side API request from the browser. You can resolve the CORS problem by adding [a CORS policy](api-management-cross-domain-policies.md#CORS) on your API(s). You can specify all the parameters manually or use wildcard `*` values. For example:
title: Use feature filters to enable a feature for a subset of users
3
+
titleSuffix: Azure App Configuration
4
+
description: Learn how to use feature filters to enable a feature for a subset of users
5
+
ms.service: azure-app-configuration
6
+
author: lisaguthrie
7
+
8
+
ms.service: azure-app-configuration
9
+
ms.topic: conceptual
10
+
ms.date: 3/9/2020
11
+
ms.author: lcozzens
12
+
13
+
---
14
+
# Use feature filters to enable a feature for a subset of users
15
+
16
+
Feature flags allow you to activate or deactivate functionality in your application. A simple feature flag is either on or off. The application always behaves the same way. For example, you could roll out a new feature behind a feature flag. When the feature flag is enabled, all users see the new feature. Disabling the feature flag hides the new feature.
17
+
18
+
In contrast, a _conditional feature flag_ allows the feature flag to be enabled or disabled dynamically. The application may behave differently, depending on the feature flag criteria. Suppose you want to show your new feature to a small subset of users at first. A conditional feature flag allows you to enable the feature flag for some users while disabling it for others. _Feature filters_ determine the state of the feature flag each time it's evaluated.
19
+
20
+
The `Microsoft.FeatureManagement` library includes two feature filters:
21
+
22
+
-`PercentageFilter` enables the feature flag based on a percentage.
23
+
-`TimeWindowFilter` enables the feature flag during a specified window of time.
24
+
25
+
You can also create your own feature filter that implements the [Microsoft.FeatureManagement.IFeatureFilter interface](/dotnet/api/microsoft.featuremanagement.ifeaturefilter).
26
+
27
+
## Registering a feature filter
28
+
29
+
You register a feature filter by calling the `AddFeatureFilter` method, specifying the name of the feature filter. For example, the following code registers `PercentageFilter`:
## Configuring a feature filter in Azure App Configuration
40
+
41
+
Some feature filters have additional settings. For example, `PercentageFilter` activates a feature based on a percentage. It has a setting defining the percentage to use.
42
+
43
+
You can configure these settings for feature flags defined in Azure App Configuration. For example, follow these steps to use `PercentageFilter` to enable the feature flag for 50% of requests to a web app:
44
+
45
+
1. Follow the instructions in [Quickstart: Add feature flags to an ASP.NET Core app](./quickstart-feature-flag-aspnet-core.md) to create a web app with a feature flag.
46
+
47
+
1. In the Azure portal, go to your configuration store and click **Feature Manager**.
48
+
49
+
1. Click on the context menu for the *Beta* feature flag that you created in the quickstart. Click **Edit**.
1. In the **Edit** screen, select the **On** radio button if it isn't already selected. Then click the **Add Filter** button. (The **On** radio button's label will change to read **Conditional**.)
55
+
56
+
1. In the **Key** field, enter *Microsoft.Percentage*.
1. Hover under the **Name** header so that text boxes appear in the grid. Enter a **Name** of *Value* and a **Value** of 50. The **Value** field indicates the percentage of requests for which to enable the feature filter.
1. Click **Apply** to return to the **Edit feature flag** screen. Then click **Apply** again to save the feature flag settings.
72
+
73
+
1. The **State** of the feature flag now appears as *Conditional*. This state indicates that the feature flag will be enabled or disabled on a per-request basis, based on the criteria enforced by the feature filter.
To see the effects of this feature flag, launch the application and hit the **Refresh** button in your browser multiple times. You'll see that the *Beta* item appears on the toolbar about 50% of the time. It's hidden the rest of the time, because the `PercentageFilter` deactivates the *Beta* feature for a subset of requests. The following video shows this behavior in action.
81
+
82
+
> [!div class="mx-imgBorder"]
83
+
> 
0 commit comments