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

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 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, cependant 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 support.
    • 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 useraccount .
    L’API REST est liée à auth_scope1, mais le jeton d’accès qui a auth_scope2 est également en mesure d’y accéder.
    • Vérifiez si cet enregistrement est actif.
    • Vérifiez ce REST, vérifiez s’il existe d’autres enregistrements, qui ont les mêmes API mais des méthodes d’application différentes, 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. Cela est attendu 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. Il n’applique pas l’authentification basée sur BasicAuth, les cookies de session et les certificats.
    L’appel d’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 API requis manquant ». Si cette API REST est trouvée, la vérification du périmètre d’authentification échoue
    Le compte d’utilisateur prédéfini est supprimé et ne doit pas être restauré à coup sûr. Exportez useraccount au format XML à partir de l’autre instance et importez-le ou créez un useraccount et modifiez la propriété glide.oauth.token.scope.useraccount système dans l’enregistrement de 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 étendues d’authentification ?
    Oui, un oauth_entity peut être lié à plusieurs étendues d’authentification, chaque jeton OAuth émis par cette oauth_entity a les mêmes étendues d’authentification.
    Différents jetons OAuth avec des périmètres d’authentification différents peuvent-ils accéder à la même API REST ?
    Oui, pour la 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, le champ d’application d’authentification renvoie les résultats.
    Le jeton d’accès OAuth avec le périmètre d’authentification useraccount peut-il accéder à n’importe quelle API REST ?
    Oui, le compte utilisateur dispose d’un accès complet au périmètre d’authentification.
    Le jeton d’accès OAuth : le champ d’application OAuth peut-il être modifié dynamiquement ?
    Oui, l’authentification incluse dans le champ d’application n’est pas codée en dur avec le jeton d’accès de la table oauth_credential . Au lieu de cela, le champ d’application d’authentification est obtenu à partir d’oauth_entity liés pendant l’exécution.
    Le jeton OAuth peut-il conserver les mêmes étendues 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 de périmètre d’authentification useraccount prédéfini est supprimé. Un nouveau périmètre d’authentification avec le nom useraccount peut être créé ?
    La création d’un nouveau périmètre d’authentification avec le même compte utilisateur ne fonctionne pas. Dans l’exécution, il utilise le sys_id au lieu du nom pour vérifier le périmètre d’authentification et modifier la propriété glide.oauth.token.scope.useraccount système en l’enregistrement de sys_id nouvellement créé.
    Si l’administrateur modifie l’authentification incluse dans le périmètre liée à oauth_entity, tous les jetons d’accès OAuth existants émis par cette entité OAuth sont-ils également modifiés ?
    Oui, le champ d’application d’authentification n’est pas directement lié au jeton d’accès OAuth, il est obtenu à partir 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 étendues d’authentification différentes ?
    Non, tous les accès au jeton sont émis par la même oauth_entity et ont toujours les mêmes étendues 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 le même point de terminaison de REST API, il peut avoir plusieurs champs d’application d’authentification correspondants.
    La vérification du périmètre d’authentification est-elle également utilisée pour BasicAuth ?
    Non, la vérification du périmètre d’authentification porte uniquement sur le jeton d’accès OAuth et le jeton OIDC, elle n’est pas demandée basicAuth et mutualAuth