Priorité des politiques d'app

les apps Access Gateway peuvent avoir plusieurs politiques. Chaque politique est associée à un chemin d'accès aux ressources contenant un URI, un type de règle et d'autres informations. Lorsqu'une requête est reçue pour une app soumise à plusieurs politiques, les politiques sont évaluées par ordre de priorité.

En général, les politiques sont évaluées dans l'ordre suivant :

  • Politique personnalisée : les politiques personnalisées sont évaluées en premier, dans l'ordre dans lequel elles ont été saisies, de façon chronologique. Le traitement commence de la première politique ajoutée à la plus récente.
  • De la plus longue à la plus courte : /a/b/c prend la priorité sur /a/b.
  • Présence ou non d'une barre oblique : les chemins d'accès aux ressources se terminant par le signe / (barre oblique) sont traités comme une correspondance exacte. Les chemins d'accès aux ressources qui ne se terminent pas par le signe / (barre oblique) sont traités comme un préfixe. Par exemple, /rest correspond à /restaurant, mais /rest/ n'y correspond pas.
  • Pour les politiques de même longueur, les politiques sensibles à la casse sont évaluées avant les politiques insensibles à la casse.
  • La politique par défaut, spécifiée par'/', est appliquée.

En général, l'ordre de tri respecte les principes suivants :

  1. Nombre total d'éléments dans l'URI. Par exemple, /a/b/c comporte trois éléments séparés par « / » (barre oblique) dans le chemin d'accès à la ressource.
  2. Sensibilité à la casse : les politiques sensibles à la casse sont positionnées avant les politiques non sensibles à la casse ayant le même nombre d'éléments.
  3. Ordre lexicographique : les politiques sont ensuite classées par ordre alphabétique.

Voici quelques exemples d'URI de politique et de leur comportement:

Règle d'URI et exemple Sensible à la casse Non sensible à la casse
Personnalisé Évaluée avant toutes les autres politiques d'URI. Évaluées dans l'ordre dans lequel elles ont été initialement saisies. Il peut s'agir d'expressions régulières dans le chemin d'accès aux ressources.
Règle d'URI : /a/b/C Exemple :/a/b/C /a : ne correspond pas. /a/b : ne correspond pas. /a/b/c : ne correspond pas. /a : ne correspond pas. /a/b : ne correspond pas. /a/b/c : correspond s'il n'y a pas de règle sensible à la casse. /a/b/C : correspond

Règle d'URI : /a/b/C Exemple : /a/b/c

/a : ne correspond pas. /a/b : ne correspond pas. /a/b/c : correspond

/a : ne correspond pas. /a/b : ne correspond pas. /a/b/c : correspond s'il n'y a pas de règle sensible à la casse.
Règle d'URI : /a/b Exemple : /a/b /a : ne correspond pas. /a/b : correspond. /a : ne correspond pas. /a/b : correspond s'il n'y a pas de règle sensible à la casse.

Règle d'URI : /a Exemple : /a

/a : correspond. /A : ne correspond pas. /a/b : ne correspond pas.

/a : correspond s'il n'y a pas de règle sensible à la casse. /A : correspond. /a/b : ne correspond pas.
Règle par défaut (« / ») Correspond à tout ce qui ne correspond pas aux règles précédentes.

/uri est considéré comme un préfixe et correspond à tout chemin commençant par /uri. /uri/ (se terminant par une barre oblique) est une correspondance exacte et ne correspond qu'à la chaîne URI exacte.

Voici quelques exemples supplémentaires, affichés par ordre de priorité.

URI

Sensible à la casse

Commentaire

/a/b/c

Oui

 Les entrées sensibles à la casse ont une priorité plus élevée que l'URI insensible à la casse.

/a/b/c

Non

/a/f

Oui

 Ces deux éléments sont marqués comme sensibles à la casse et comportent le même nombre d'éléments (deux) triés par ordre alphabétique.

/a/b

Oui

/a/e

Non

 Ces deux éléments sont marqués comme insensibles à la casse et comportent le même nombre d'éléments (deux) triés par ordre alphabétique, mais après la sensibilité à la casse, il y a deux règles d'élément.

/a/b

Non

/a

Non