web-dev-qa-db-fra.com

La fonction Lambda est renvoyée à CloudFront.

J'essaie de suivre les instructions ici https://medium.com/@tom.cook/Edge-lambda-cloudfront-custom-headers-3d134a2c18a2

CloudFront est assis avec succès devant un fichier HTML statique "hello world" S3 et je souhaite définir des en-têtes supplémentaires à l'aide de lambda Edge, mais je reçois une erreur. Ce qui est vraiment frustrant, c’est que je ne trouve aucun journal de l’erreur pour corriger ce qui ne va pas. Voici ce que montre le navigateur.

ERROR

The request could not be satisfied.

The Lambda function returned an invalid request or response to CloudFront. 
Generated by cloudfront (CloudFront)
Request ID: 2Cqex7euzH0Iigps58i9tMVxdqAaLznL2ZjwqR1sW1AZHz6x2EwfMA==

Voici le code de mon lambda simple:

exports.handler = (event, context, callback) => {
    console.log(event)
    callback(null, 'Hello from Lambda');
};

Le type de déclencheur est viewer-response et est associé à ma distribution CloudFront (avec Cache Behavior: *, si cela compte). Le lambda a un rôle correspondant à AWSLambdaBasicExecutionRole, qui donne un accès en écriture à Cloudwatch.

Dès que j'active le déclencheur, la réponse à une requête Web change du code HTML "Hello world" à l'erreur ci-dessus. Je sais donc que cela déclenche le lambda. Mais dans le tableau de bord lambda, il ne montre aucune invocation ni erreur. Aucun journal n'apparaît dans Cloudwatch. Le tableau de bord CloudFront affiche les erreurs (5xx), mais rien de lambda.

Si je teste ensuite ma fonction dans la console lambda en cliquant sur la fonction déployée, en configurant l'événement de test comme "En-tête de réponse CloudFront Modify" et en cliquant sur Test, l'opération réussit. Et Cloudwatch affiche les journaux et la sortie de la console pour le test! Mais toujours rien dans les journaux pour l'invocation en direct.

Ma seule théorie est que quelque chose ne va pas avec les autorisations, que CloudFront ne peut pas réellement invoquer le lambda (explique pourquoi il n'y a rien dans le tableau de bord lambda). La dernière chose est que les journaux CloudFront (dans S3) affichent la demande Web avec l'erreur 502 et LambdaValidationError, mais je ne peux pas savoir si cela aide.

aws-lambdaamazon-cloudfrontamazon-cloudwatch
7
lordbyron

L'exemple de l'article de blog que vous regardez était valable tant que Lambda @ Edge était encore en aperçu (accès limité à des clients spécifiques, avant le lancement de la disponibilité générale), mais ce n'est plus correct. Peu de temps avant le lancement du service, les structures de données ont été modifiées.

Les structures de données d'en-tête de réponse ressemblaient auparavant à ceci:

headers['Strict-Transport-Security'] = "max-age=31536000; includeSubdomains; preload";
headers['Content-Security-Policy']   = "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'";
headers['X-Content-Type-Options']    = "nosniff";

Les nouvelles structures ressemblent à ceci:

headers['strict-transport-security'] = [{
    key:   'Strict-Transport-Security', 
    value: "max-age=31536000; includeSubdomains; preload"
}];

headers['content-security-policy'] = [{
    key:   'Content-Security-Policy', 
    value: "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'; object-src 'none'"
}];

headers['x-content-type-options'] = [{
    key:   'X-Content-Type-Options',
    value: "nosniff"
}];

Les clés de l'objet externe doivent être l'équivalent minuscule de la valeur key dans chaque membre des objets internes. Cette modification des structures de données était très probablement nécessaire afin de refléter plus précisément la manière dont les en-têtes HTTP doivent être traités, car dans HTTP/1.x, ils ne sont pas sensibles à la casse, alors que dans un objet Javascript, les clés sont sensibles à la casse.

Si la structure renvoyée par votre code n'est pas conforme à ce que CloudFront demande à Lambda @ Edge de renvoyer, l'erreur que vous voyez sera effectivement renvoyée. Il n'y a pas de journaux générés car il n'y a pas d'endroit où aller pour les journaux. Cette erreur se produit en dehors de Lambda, du côté CloudFront de la limite d'interface entre Lambda et CloudFront, qui ne génère aucun journal accessible à l'utilisateur.

Voir la documentation de la Response Event Structure .

5
Michael - sqlbot

Il y a quelques "pièges" communs à Lambda @ Edge et CloudFront. Tu dois:

  • Publier une nouvelle version de votre fonction Lambda
  • Mettez à jour l'association CloudFront Lambda vers votre nouvelle version, par exemple. arn:aws:lambda:us-east-1:572007530218:function:gofaas-WebAuthFunction:45
  • Recherchez les journaux Lambda @ Edge dans la région du demandeur

Et pour autant que je sache, vous ne pouvez pas voir les statistiques relatives aux invocations à partir des "copies" de votre fonction principale Lambda réparties sur les "bords". 

Cela diffère du flux "normal" de la console Web Lambda consistant à enregistrer une modification de code et à accéder aux journaux à partir de l'onglet de surveillance.

Jetez un coup d'œil à cette application standard qui automatise le déploiement d'un gestionnaire Lambda @ Edge OAuth et Cookie }, qui prend beaucoup de peine à le configurer.

1
Noah Zoschke