Skip to main content
Afin d’offrir à nos clients la solution la plus fiable et la plus évolutive, Auth0 a marqué Tenant Logs Search Engine v2 comme déprécié au profit de v3. Auth0 migre de façon proactive les clients non concernés par ce changement, tandis que ceux qui pourraient l’être sont avisés qu’ils doivent opter pour v3 pendant la période de grâce prévue.

​
Fonctionnalités touchées

Vous êtes concerné si vous remplissez tous les critères suivants :
  • Tenants créés le 21 mai 2019 ou avant
  • Tenants hébergés dans le Public Cloud d’Auth0 dans les régions AU ou EU
  • Vous utilisez le endpoint GET /api/v2/logs ou le endpoint GET /api/v2/users/{user_id}/logs avec le paramètre include_totals=true ou le paramètre q.
  • Vous parcourez plus de 1000 résultats par pagination.
  • Vous utilisez la Delegated Admin Extension. Les anciennes versions de l’extension continueront de fonctionner après la migration de votre tenant vers Logs Search Engine v3; toutefois, il se peut que les totaux de pagination affichés lors de la consultation des logs soient inexacts. La mise à jour vers la version 3.7 de l’extension corrige ce problème.
Les tenants suivants ne sont pas concernés :
  • Tenants Cloud dans la région US. La région US a été entièrement migrée et utilise déjà Search Engine v3.
  • Tenants Private Cloud (La migration pour les clients Private Cloud commencera à une date ultérieure.)
  • Tenants Cloud dans les régions EU et AU qui :
    • N’utilisent pas du tout les endpoints GET /api/v2/logs ou GET /api/v2/users/{user_id}/logs de la Management API.
    • Consultent les logs uniquement dans la section Logs du Dashboard.
    • Utilisent le GET /api/v2/logs endpoint avec la méthode by checkpoint (à l’aide du paramètre from).
    • Consultent les logs à l’aide de l’une des extensions Auth0 Logs to External Service Dashboard (qui utilisent la méthode by checkpoint).

​
Vérifier la migration des requêtes

Auth0 génère un seul log d’un type et d’une description donnés toutes les 60 minutes. Peu importe le nombre d’appels aux endpoints concernés effectués au moyen de fonctionnalités dépréciées, vous ne verrez qu’un seul log par fonctionnalité dépréciée par heure. Si vous modifiez vos requêtes, vous devrez attendre 60 minutes avant de pouvoir conclure avec certitude que l’absence de nouveaux logs depnote signifie que le comportement déprécié a bien été retiré de votre code. Vous pouvez effectuer la recherche suivante dans les logs de votre tenant afin de repérer les requêtes qui entraîneraient des erreurs après la migration vers v3 : type:depnote AND description:*logs* Ces entrées de log contiennent un champ description qui précise le comportement déprécié que vous utilisez. Vous pouvez aussi vérifier les champs details.request.path et client_name pour voir quelle application envoie des requêtes à GET /api/v2/logs ou à GET /api/v2/users/{user_id}/logs.

​
Changements

Les changements incompatibles sont mineurs, mais vous devriez vérifier vos requêtes pour vous assurer que les résultats obtenus correspondent à vos attentes. Les changements incompatibles sont liés à :

​
Pagination

  • Lorsque votre tenant sera migré vers logs v3, la valeur du champ total renvoyée dans le résultat sommaire d’une requête à GET /api/v2/logs ou à GET /api/v2/users/{user_id}/logs changera. Lorsque vous recherchez des logs à l’aide de search engine v2, le champ totals dans vos résultats indique le nombre de logs qui correspondent à la requête fournie. Toutefois, dans v3, le champ totals indique combien de logs sont renvoyés dans la page (un peu comme le champ length). Afin d’éviter toute perturbation, si votre application s’appuie sur le champ total pour la pagination, vous devriez mettre à jour votre logique afin de tenir compte de ce changement.
  • Il existe déjà une limite de 100 logs par requête. Lorsque votre tenant sera migré vers logs v3, vous pourrez paginer sur un maximum de 1 000 résultats de recherche seulement; toute requête portant sur plus de 1 000 résultats renverra donc une erreur. Afin d’éviter toute perturbation, vous devriez revoir vos requêtes pour éviter cette limite ou gérer les erreurs en conséquence.

​
validation du paramètre q

  • La syntaxe de requête utilisée avec le paramètre q dans GET /api/v2/logs comporte de légères modifications dont il faut tenir compte. Lorsque votre tenant sera migré vers logs v3, cette validation sera appliquée, ce qui fera en sorte que cette requête renverra une erreur. Pour éviter toute perturbation, vous devriez revoir vos requêtes pour vous assurer qu’elles respectent la syntaxe de requête prise en charge.
  • Le paramètre q contient un champ non valide. Lorsque votre tenant sera migré vers logs v3, cette validation sera appliquée, ce qui fera en sorte que cette requête renverra une erreur. Pour éviter toute perturbation, vous devriez revoir vos requêtes pour vous assurer qu’elles ne contiennent que des champs interrogeables.

​
Activer Tenant Log Search v3

Après avoir examiné vos requêtes, vous pouvez activer Tenant Logs Search Engine v3 dans le Dashboard.
  1. Accédez à Tenant Settings > Advanced.
  2. Faites défiler la page jusqu’à Migrations.
  3. Désactivez le commutateur Legacy Logs Search V2. Lorsque ce commutateur est désactivé, le search engine v2 des logs, désormais déprécié, est désactivé et l’utilisation de search engine v3 est forcée. Si vous ne voyez pas la bascule Legacy Logs Search V2, c’est que vous avez déjà été migré vers v3. Aucune autre action n’est requise.
Si vous avez besoin d’aide pour la migration, communiquez avec nous par l’intermédiaire du Support Center.

​
Pour en savoir plus