Dépannage du périmètre de l’API REST

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 3 minutes de lecture

    • Les actions de dépannage peuvent aider à résoudre les problèmes courants lors de la configuration ou de l’exécution du périmètre de l’API REST.

    Tableau 1. Dépannage
    Problème Action
    L’API REST est liée au périmètre d’authentification, mais en cours d’exécution, il n’y a pas de vérification du périmètre d’authentification, même à l’aide de l’authentification par jeton de porteur.
    • Assurez-vous que l’enregistrement sys_api_access_policy est actif. L’exécution ignore les enregistrements inactifs.
    • Vérifiez si la propriété com.glide.rest.api.auth.scope.check.enable est définie sur faux.
    • Vérifiez si le jeton OAuth a un périmètre d’authentification de compte utilisateur .
    L’API REST est liée à auth_scope1, mais le jeton d’accès qui a auth_scope2 est également capable d’y accéder.
    • Vérifiez si cet enregistrement est actif.
    • Vérifiez ce REST, vérifiez si d’autres enregistrements, qui ont les mêmes API, mais différentes appliquent des méthodes, des versions ou des ressources.
    L’API REST est liée au périmètre d’authentification, mais en cours d’exécution, il n’y a pas de vérification du périmètre d’authentification pour basicAuth et mutualAuth. C’est normal car le périmètre d’authentification de l’API REST ne s’applique qu’au jeton d’accès OAuth ou au jeton OIDC. Elle n’applique pas BasicAuth, les cookies de session et l’authentification basée sur certificat.
    L’appel de l’API REST renvoie 403 lors de l’utilisation du jeton d’accès OAuth. Vérifiez le message d’erreur « Périmètre d’accès à l’API requis manquant ». Si elle est trouvée, la vérification du champ d’application d’authentification échoue pour cette API REST
    Le compte d’utilisateur prédéfini est supprimé et la restauration n’est pas sûre. Exporter useraccount au format xml depuis l’autre instance et l’importer ou créer un useraccount et modifier la propriété glide.oauth.token.scope.useraccount système dans l’enregistrement sys_id nouvellement créé.

    Forum Aux Questions

    Voici quelques-unes des questions fréquemment posées lors de l’utilisation du périmètre d’authentification de l’API REST :

    Un jeton OAuth peut-il être lié à plusieurs périmètres d’authentification ?
    Oui, un oauth_entity peut être lié à plusieurs champs d’application d’authentification, tous les jetons OAuth émis par cet oauth_entity ont les mêmes champs d’application d’authentification.
    Différents jetons OAuth avec différents champs d’application d’authentification peuvent-ils accéder à la même API REST ?
    Oui, pour une même API REST, différents périmètres d’authentification peuvent y accéder. Tant qu’un périmètre d’authentification est mis en correspondance, il renvoie les résultats.
    Le jeton d’accès OAuth avec le périmètre d’authentification du compte utilisateur peut-il accéder à toutes les API REST ?
    Oui, le compte utilisateur dispose d’un accès complet au périmètre d’authentification.
    Le périmètre OAuth du jeton d’accès OAuth peut-il être modifié dynamiquement ?
    Oui, l’authentification incluse dans le périmètre n’est pas codée en dur avec le jeton d’accès dans la table oauth_credential . Au lieu de cela, le périmètre d’authentification est obtenu à partir des oauth_entity liés pendant l’exécution.
    Le jeton OAuth peut-il conserver les mêmes champs d’application d’authentification après l’actualisation ?
    Oui, le périmètre d’authentification ne changera pas après l’actualisation du jeton, sauf si oauth_admin modifiez le périmètre d’authentification lié à oauth_entity.
    L’enregistrement du champ d’application d’authentification du compte d’utilisateur prédéfini est supprimé. Un nouveau champ d’application d’authentification portant le nom useraccount peut-il être créé ?
    La création d’un nouveau champ d’application d’authentification avec le même compte d’utilisateur ne fonctionne pas. Dans l’exécution, il utilise le sys_id au lieu du nom pour effectuer la vérification du périmètre d’authentification et modifier la propriété glide.oauth.token.scope.useraccount système sur l’enregistrement de sys_id nouvellement créé.
    Si l’administrateur modifie l’authentification incluse dans le périmètre lié à oauth_entity, tous les jetons d’accès OAuth existants émis par cette entité OAuth sont-ils également changés ?
    Oui, le périmètre d’authentification n’est pas directement lié au jeton d’accès OAuth qu’il reçoit de oauth_entity pendant l’exécution.
    Différents jetons d’accès OAuth émis par le même oauth_entity peuvent-ils avoir des champs d’application d’authentification différents ?
    Non, tous les accès au jeton sont émis par le même oauth_entity et ont toujours les mêmes champs d’application d’authentification.
    Un utilisateur peut-il définir différents champs d’application d’authentification pour un point de terminaison particulier ?
    Non, il existe une vérification de contrainte unique pour un point de terminaison d’API REST particulier. Toutefois, pour un même point de terminaison d’API REST, il peut avoir plusieurs périmètres d’authentification correspondants.
    La vérification du champ d’application d’authentification est-elle également utilisée pour BasicAuth ?
    Non, la vérification du champ d’application d’authentification est uniquement un jeton d’accès OAuth et un jeton OIDC, elle n’est pas demandée basicAuth et mutualAuth