2
votes

Comment résoudre le problème de blocage de lecture cross-origin (CORB) avec une passerelle AWS lambda?

J'essayais de faire fonctionner mon application React sur mon hôte local pour parler à AWS. J'ai activé CORS et les OPTIONS sur l'API.

Chrome donne cette erreur maintenant

Cross-Origin Read Blocking (CORB) a bloqué la réponse cross-origin https: //xxxxxx.execute- api.us-east-2.amazonaws.com/default/xxxxxx avec application de type MIME / json. Voir https://www.chromestatus.com/feature/5629709824032768 pour plus de détails.

J'ai inspecté l'onglet réseau et l'appel d'options est en cours et les OPTIONS l'envoient dans l'en-tête de la réponse

access-control-allow-headers: Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token
access-control-allow-methods: DELETE,GET,HEAD,OPTIONS,PATCH,POST,PUT
access-control-allow-origin: *

Comment puis-je Je corrige ce problème CORB et fais ma première fonction lambda?

amazon-web-services aws-lambda

0 commentaires

3 Réponses :

0
votes

CORB est une protection spécifique à Chromium et n'est pas directement liée à votre configuration CORS du côté AWS.

Votre serveur renvoie-t-il les en-têtes requis par CORB? X-Content-Type-Options: nosniff et un Content-Type correct?

Vous pouvez en savoir plus sur CORB sur la page Web Chromium à l'adresse https : //www.chromium.org/Home/chromium-security/corb-for-developers

1 commentaires

Hé merci pour l'aide. J'ai pu résoudre le problème moi-même et j'ai publié ma réponse ici: stackoverflow.com/a/54824932/1278480

2
votes

Je devais le découvrir. J'avais besoin de faire ces deux choses pour le faire fonctionner

1. Activez CORS sur la passerelle d'API Amazon pour votre API

Cela créera un gestionnaire de méthode OPTIONS http et vous pourrez autoriser les publications de votre site Web en définissant la bonne valeur pour access-control-allow-origin en-tête.

2. Assurez-vous que la gestion de votre méthode POST envoie les bons paramètres lors de l'envoi de la réponse

import json
from botocore.vendored import requests

API_URL = "https://aladdin.mammoth.io/api/v1/user-registrations"

def lambda_handler(event, context):
    if event['httpMethod'] == 'POST':
        data = json.loads(event['body'])
        # YOUR CODE HERE
        return {
            'statusCode': 200,
            'body': json.dumps({}),
            'headers': {
              'access-control-allow-headers': 'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token',
              'access-control-allow-methods': 'DELETE,GET,HEAD,OPTIONS,PATCH,POST,PUT',
              'access-control-allow-origin': '*'
            }
        }
    return {
        'statusCode': 200,
        'body': json.dumps({})
    }

1 commentaires

Oh, c'était ça! Si quelqu'un d'autre utilisant fetch côté client tombe sur cela, n'oubliez pas de définir le mode sur cors .

0
votes

J'ai corrigé ce problème pour les fichiers image en mettant à jour les métadonnées Content-Type sous Propriétés dans S3 - image / jpeg pour les fichiers JPEG et image / png pour les fichiers PNG.

Mon application télécharge des fichiers image via multer-s3 et il semble que cela s'applique < code> Content-Type: 'application / x-www-form-urlencoded' . Il a une option contentType avec auto content-type -detect feature - cela devrait éviter les en-têtes incorrects et résoudre le problème CORB.

Il semble que la dernière mise à jour de la version de Chrome 76 inclut l'écoute des en-têtes d'URL de fichiers distants, en particulier Content-Type . CORB n'était pas un problème pour les autres navigateurs tels que Firefox, Safari et les navigateurs intégrés aux applications, par exemple. Instagram.

0 commentaires