1
J'ai fait la configuration de cors dans l'en-tête de réponse de mon api correctement.aws cognito && apiGateway renvoie le statut 401
quand je testé mon api via postier avec un jeton attaché en-tête (« autorisation »), il est revenu 200.
j'ai vérifié mes frontend la récupération du code validé pour demander que api, il semble qu'il n'y ait erreur ou faute.
comment cela peut-il se produire? Est-ce que quelqu'un qui a souffert de même que ce que je me bats maintenant.
Ajouté:
ma fin avant la récupération du code ressemble à ceci.
export const getDoc = async (docId, token) => {
const path = `${apiGateway.URL}`;
const body = {
docId: docId
};
const headers = {
Authorization: token,
'Content-Type': 'application/json'
};
const result = await fetch(path, {
body,
headers,
});
if (result.status !== 200) {
throw new Error('failed to get doc');
}
return result.json();
};
@VijayanathViswanathan bien sûr, j'ai fait la configuration fondamentale de CORS dans la passerelle API. Comme je l'ai mentionné ci-dessus, API appel succès dans post man. mais cela ne fonctionne pas dans mon code frontend –
Tant l'en-tête de demande 'Authorization' que le 'Content-Type: application/json' déclenchent votre navigateur pour effectuer un contrôle en amont. Donc le problème est exactement ce que j'ai décrit dans mon commentaire précédent: Vous devez reconfigurer le serveur pour ne pas avoir besoin d'autorisation pour les requêtes OPTIONS. La raison en est que le navigateur n'envoie pas l'en-tête de demande d'autorisation lorsqu'il effectue cette demande OPTIONS de contrôle en amont. La raison pour laquelle ce n'est pas parce que le but entier de cette demande OPTIONS est pour le navigateur de demander au serveur, Autorisez-vous les demandes d'origine croisée qui ont l'en-tête d'autorisation? – sideshowbarker