Problèmes courants et signalement de bugs

Lorsque vous rencontrez un problème avec le Web Push, il peut être difficile de le déboguer. pour obtenir de l'aide. Ce document décrit certains des problèmes courants et ce que vous devez à faire si vous avez trouvé un bug dans Chrome ou Firefox.

Avant de nous pencher sur le débogage du mode push, vous rencontrez peut-être des problèmes de débogage. service workers eux-mêmes, que le fichier ne se met pas à jour, qu'il ne parvient pas à s'enregistrer ou généralement un comportement inhabituel. Il existe un un super document sur le débogage des service workers que je vous recommande vivement de consulter si vous débutez développement de service workers.

Lors du développement et du test de la fonctionnalité Web push, vous devez suivre deux étapes distinctes : chacun avec son propre ensemble de problèmes / problèmes courants:

  • Envoi d'un message:vérifiez que les messages ont bien été envoyés. Vous devriez obtenir un code HTTP 201. Dans le cas contraire : <ph type="x-smartling-placeholder">
      </ph>
    • Recherchez les erreurs d'autorisation:si vous recevez un message d'autorisation consultez le Problèmes d'autorisation.
    • Autres erreurs d'API:si vous recevez une réponse avec un code d'état autre que 201, consultez la section Codes d'état HTTP pour en savoir plus sur la cause du problème.
  • Réception d'un message: si vous parvenez à envoyer un message, mais que le message n'est pas reçu dans le navigateur: <ph type="x-smartling-placeholder">

Si vous n'êtes pas en mesure d'envoyer ni de recevoir un message push et les sections correspondantes dans ce document ne permettent pas de résoudre le problème. Il se peut que vous ayez trouvé dans le mécanisme d'envoi lui-même. Dans ce cas, reportez-vous au Signalement de bugs pour remplir un rapport de bug de qualité avec toutes les informations nécessaires le processus de correction des bugs.

Avant de commencer, j'aimerais vous signaler que Firefox et le Le service Mozilla AutoPush génère des messages d'erreur très positifs. Si vous êtes bloqué et si vous ne savez pas d'où vient le problème, faites un test dans Firefox et voyez si un message d'erreur plus utile.

Problèmes d'autorisation

Les problèmes d'autorisation sont l'un des problèmes les plus courants rencontrés par les développeurs avec le Web push. Il s'agit généralement d'un problème lié à la configuration les clés de serveur d'application (ou clés VAPID) du site

La manière la plus simple d'accepter le mode Push dans Firefox et Chrome est de fournir un applicationServerKey dans l'appel subscribe(). L’inconvénient est que En cas de divergence entre les clés de votre frontend et celles du serveur, erreur d'autorisation.

Sur Chrome et FCM

Pour Chrome, qui utilise FCM en tant que service push, vous recevez une notification réponse UnauthorizedRegistration de FCM pour une plage de des erreurs, toutes impliquant les clés du serveur d'applications.

Vous recevrez une erreur UnauthorizedRegistration dans l'un des cas suivants situations suivantes:

  • Si vous ne définissez pas d'en-tête Authorization dans la requête adressée à FCM.
  • La clé d'application utilisée pour abonner l'utilisateur ne correspond pas à la clé utilisée pour signer l'en-tête "Authorization".
  • L'expiration n'est pas valide dans votre jeton JWT, c'est-à-dire qu'elle dépasse 24 heures. Le jeton JWT a expiré.
  • Le jeton JWT est mal formé ou comporte des valeurs non valides.

La réponse d'erreur complète se présente comme suit:

<html>
  <head>
    <title>UnauthorizedRegistration</title>
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <h1>UnauthorizedRegistration</h1>

    <h2>Error 400</h2>
  </body>
</html>

Si ce message d'erreur s'affiche dans Chrome, effectuez un test dans Firefox pour voir si elle peut fournir plus d’informations sur le problème.

La fonctionnalité Push automatique de Firefox et de Mozilla

Firefox et Mozilla AutoPush fournissent un ensemble convivial de messages d'erreur pour Authorization problèmes.

Vous recevrez également une réponse d'erreur Unauthorized de Mozilla AutoPush si l'en-tête Authorization n'est pas inclus dans votre mode push requête.

{
  "errno": 109,
  "message": "Request did not validate missing authorization header",
  "code": 401,
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "error": "Unauthorized"
}

Si l'expiration de votre jeton JWT a expiré, vous recevez également une Erreur Unauthorized avec un message expliquant que le jeton a est arrivé à expiration.

{
  "code": 401,
  "errno": 109,
  "error": "Unauthorized",
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "message": "Request did not validate Invalid bearer token: Auth expired"
}

Si les clés du serveur d'applications sont différentes abonné et lorsque l'en-tête "Authorization" a été signé, un Not Found est renvoyée:

{
  "errno": 102,
  "message": "Request did not validate invalid token",
  "code": 404,
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "error": "Not Found"
}

Enfin, si votre jeton JWT contient une valeur non valide (par exemple, si la valeur "alg" est inattendue), vous recevez l'erreur suivante de la part de Mozilla AutoPush:

{
  "code": 401,
  "errno": 109,
  "error": "Unauthorized",
  "more_info": "http://autopush.readthedocs.io/en/latest/http.html#error-codes",
  "message": "Request did not validate Invalid Authorization Header"
}

Codes d'état HTTP

Plusieurs problèmes peuvent entraîner l'envoi d'un code de réponse autre que 201 à partir d'une push. Vous trouverez ci-dessous la liste des codes d'état HTTP et leur signification en mode Web push.

Code d'état Description
429 Trop de requêtes. Votre serveur d'applications a atteint la limite de débit associée à une push. La réponse du service doit inclure le message "Retry-After" (Réessayer après). en-tête pour indiquer le délai avant qu'une autre demande puisse être effectuée.
400 Demande incorrecte. L'un de vos en-têtes est incorrect ou mal formaté.
404 Introuvable. Dans ce cas, vous devez supprimer l'abonnement PushSubscription de votre et attendre la possibilité de réabonner l'utilisateur.
410 Supprimé. L'abonnement n'est plus valide et doit être supprimé de votre de votre backend. Vous pouvez reproduire cela en appelant `unsubscribe()` sur un `PushSubscription`.
413 Charge utile trop grande. Taille minimale de la charge utile qu'un service push doit est de 4 096 octets (ou 4 Ko). Une valeur plus élevée peut entraîner cette erreur.

Si le code d'état HTTP ne figure pas dans cette liste et que le message d'erreur n'apparaît pas consultez la page Web Push Protocol technique pour vérifier code d'état est référencé, ainsi qu'un scénario dans lequel ce code d'état peut être utilisée.

Problème de chiffrement de la charge utile

Si vous parvenez à déclencher un message push (par exemple, envoyer un message à une adresse push et recevez un code de réponse 201), mais l'événement push ne se déclenche jamais votre service worker, cela indique normalement que le navigateur n'a pas réussi déchiffrer le message reçu.

Dans ce cas, un message d'erreur devrait s'afficher dans les outils de développement de Firefox. console comme ceci:

Outils pour les développeurs Firefox avec un message de déchiffrement

Pour vérifier si c'est le cas dans Chrome, procédez comme suit:

  1. Accédez à about://gcm-internals et cliquez sur le bouton "Start Recording" (Démarrer l'enregistrement). .

Enregistrement interne GCM dans Chrome.

  1. Déclenchez un message push et consultez le journal des échecs de déchiffrement du message.

Journal de déchiffrement des données internes GCM.

En cas de problème lors du déchiffrement de la charge utile, une erreur similaire à celui présenté ci-dessus. Notez les AES-GCM decryption failed s'affiche dans la colonne "Détails".

Si vous rencontrez ce problème, certains outils peuvent vous aider à déboguer le chiffrement:

Problème de connexion

Si vous ne recevez pas d'événement push dans votre service worker et si vous ne recevez pas des erreurs de déchiffrement, il se peut que le navigateur ne se connecte pas un service push.

Dans Chrome, vous pouvez vérifier si le navigateur reçoit des messages en examinant "Recevoir le journal des messages" (sic) dans about://gcm-internals.

Les composants internes de GCM reçoivent le journal des messages.

Si le message n'arrive pas à temps, assurez-vous que l'état de connexion de votre navigateur est CONNECTED:

État de connexion aux données internes GCM

Si la mention "CONNECTÉ" n'est pas affichée, vous devrez peut-être supprimer votre profil actuel, puis créez-en une. Si ne résout toujours pas le problème, veuillez envoyer un rapport de bug comme suggéré ci-dessous.

Générer des rapports de bugs

Si aucune des solutions ci-dessus ne permet de résoudre votre problème veuillez signaler le problème sur le navigateur avec lequel vous rencontrez problème concernant:

Pour Chrome, posez le problème ici: https://bugs.chromium.org/p/chromium/issues/list Pour Firefox, vous devez signaler le problème sur: https://bugzilla.mozilla.org/

Pour générer un rapport de bug de qualité, vous devez fournir les informations suivantes:

  • les navigateurs dans lesquels vous avez effectué les tests (par exemple, Chrome version 50, Chrome 51, Firefox) ; version 50, Firefox version 51).
  • Exemple de PushSubscription qui illustre le problème.
  • Inclure tous les exemples de requêtes (c'est-à-dire le contenu des requêtes réseau à une requête push service, y compris les en-têtes).
  • Incluez également tous les exemples de réponses des requêtes réseau.

Si vous pouvez fournir un exemple reproductible, soit du code source, soit un site Web hébergé permet souvent d'accélérer le diagnostic et la résolution du problème.

Étapes suivantes

Ateliers de programmation