Limites et pratiques exemplaires pour la recherche d’utilisateurs

​

Solutions de rechange au terminal List or Search Users

Le terminal List or Search Users (GET /users) de Management API ne convient pas aux chemins sensibles à la latence ou pour lesquels l’exactitude est essentielle. Comme sa cohérence est éventuelle, les résultats de recherche peuvent ne pas refléter les écritures très récentes. De plus, il est soumis à une courte limite de temps d’exécution des requêtes (environ 2 secondes) sur une infrastructure partagée; les requêtes peuvent donc dépasser cette limite sur les locataires volumineux ou en période de forte charge.

• N’utilisez pas le terminal List or Search Users dans le cadre d’un processus d’authentification, pour la liaison de comptes ou lorsqu’une cohérence immédiate est requise. Utilisez plutôt les terminaux de Management API pour obtenir des utilisateurs par ID ou par courriel.
• N’utilisez pas le terminal List or Search Users pour énumérer ou exporter des utilisateurs. Utilisez plutôt les exportations groupées d’utilisateurs.
• N’interrogez pas le terminal List or Search Users de façon répétée et n’effectuez pas de recherches dans les points d’extension du flux de connexion, comme les Actions post-login. Abonnez-vous plutôt aux flux d’événements (user.created, user.updated, user.deleted) pour que les systèmes externes restent synchronisés en continu avec les données des utilisateurs.

​

Recommandations en matière de performance

Suivez les lignes directrices ci-dessous pour améliorer la performance de la recherche d’utilisateurs :

• Par défaut, le terminal List or Search Users renvoie les résultats dans un ordre déterministe : une même requête produit donc chaque fois les mêmes résultats, ordonnés de façon logique. La recherche non déterministe est plus rapide. Si la recherche déterministe n’est pas nécessaire dans votre cas d’utilisation, optez plutôt pour la recherche non déterministe en définissant primary_order=false.
• Échappez le caractère d’espacement (par exemple, écrivez q=name:John Doe sous la forme q=name:John\ Doe).
• Limitez l’utilisation des caractères de remplacement, surtout sur de grands ensembles de données. Si vous en utilisez, placez-les de préférence en suffixe du terme de recherche plutôt qu’en préfixe.
• Privilégiez le filtrage ou la recherche sur des champs indexés de premier niveau plutôt que sur des champs de forme libre ou à valeurs multiples (comme app_metadata et user_metadata).
• Pour les attributs définis par l’utilisateur dans app_metadata et user_metadata :
  • Limitez la taille des champs de métadonnées à 2 Ko.
  • Utilisez des types de données cohérents et des noms fixes pour les propriétés de métadonnées.
  • Évitez les schémas volumineux et les structures profondément imbriquées.
• Évitez les critères de recherche qui renvoient plus de 1 000 résultats.
• Évitez les requêtes d’existence (par exemple, « tous les utilisateurs ayant une propriété donnée, peu importe sa valeur »).

​

Limites

• La recherche renvoie au maximum 1 000 utilisateurs, même si un plus grand nombre d’utilisateurs correspondent à votre requête. Lorsque vous utilisez l’API, les résultats volumineux sont paginés.
• La taille des profils utilisateur Auth0 est limitée à 10 Ko.
• Le terminal List or Search Users impose une limite de 1 Mo par utilisateur pour les données utilisateur pouvant être indexées, interrogées et renvoyées.
• Les profils utilisateur créés avant l’instauration de la limite de taille actuelle peuvent la dépasser. Pour récupérer tous les attributs d’un profil utilisateur volumineux, obtenez les utilisateurs par ID ou par courriel.
• Le terminal List or Search Users ne prend pas en charge le tri par app_metadata ou user_metadata.