2016-02-06 17 views
5

Mam WebApp reag.js/redux/webpackt/es6 ... i api w go z MUX z goryla.
Po wywołaniu funkcji poniżej mój nagłówek jest pusty i zawartość również.Fetch answer empty ze względu na preflight?

Używam tego pakietu w moim webapp do nawiązywania połączeń

"isomorphic-fetch": "^2.2.1", 

moim przykładzie wywołanie

export function Login(userData) { 
    return dispatch => { 
    fetch(API + '/login', { 
     method: 'post', 
     headers: { 
     'Accept': 'application/json', 
     'Content-Type': 'application/json', 
     }, 
     body: JSON.stringify({ 
     email: userData.email, 
     password: userData.password, 
     }), 
    }) 
    .then(response => { 
     console.log(response); 
     console.log(response.statusText); 
     console.log(response.status); 
     console.log(response.headers); 
     console.log(response.headers.get("Authorization")); 
     console.log(response.json()); 
     return response.json() 
     if (response.status >= 200 && response.status < 300) { 
     console.log(response); 
     dispatch(LoginSuccess(response)); 
     } else { 
     const error = new Error(response.statusText); 
     error.response = response; 
     dispatch(LoginError(error)); 
     throw error; 
     } 
    }).then(function(json) { 
     console.log('parsed json' + json) 
    }) 
    .catch(error => { console.log('request failed', error); }); 
    } 

Na początku miałem problem z Cors How to handle preflight CORS requests on a Go server użyłem tego rozwiązania

Możemy sprawdzić połączenie wewnątrz konsoli:

login OPTIONS 200 fetch auths.actions.js:38 352 B 1 ms  
login POST  200 json Other 567 B 82 ms 

Kiedy patrzę wewnątrz mojej odpowiedzi POST Header mam:

HTTP/1.1 200 OK 
Access-Control-Allow-Headers: Accept, Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization 
Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, PATCH, DELETE 
Access-Control-Allow-Origin: http://localhost:3000 
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE0NTQ3NTcxNjEsInVzZXJfaWQiOiI1NmI1YjZlOTFhZTMzYjAwMDFhYmE1MTQifQ.WGoTMxm6OuN24Olwr93J3pND9dFLCtG5MyiRbqLWeD244JtDzq0bGgQMixeZxyuxwGK3u8KhyWD7Rr6iZAGNpA 
Content-Type: application/json 
Date: Sat, 06 Feb 2016 11:12:41 GMT 
Content-Length: 2 

Więc odpowiedź obsłużyć mój inspekcji wstępnej informacji nie mój post? Ponieważ nie ma nic wewnątrz urządzenia response.headers i response.headers.get("Authorization") Coś jest nie tak?

+1

jesteś świadomy wracasz z ówczesnego() przewodnika po logach? – Salva

Odpowiedz

7

Wystąpił problem polegający na tym, że moje nagłówki zostały wysłane, poprawnie odebrane (karta sieciowa chrome poprawnie pokazuje wszystkie wysłane nagłówki), ale nie mogłem uzyskać do nich dostępu w js (response.headers było puste). Jak opisano w Fetch get request returns empty headers, stało się tak, ponieważ serwer nie ustawił nagłówka Access-Control-Expose-Headers, co spowodowało, że potrzebne nagłówki nie były narażone na działanie js. Więc rozwiązaniem jest dodanie ten nagłówek na serwerze i voila, teraz nagłówki są dostępne w JS:

Access-Control-Expose-Headers: <header-name>, <header-name>, ... 

Nagłówek pobiera listę oddzielonych przecinkami nazw nagłówków być narażone na przeglądarce.

Dla dodatkowej informacji na temat dlaczego jest potrzebny ten nagłówek, zobacz Why is Access-Control-Expose-Headers needed?

+0

W moim rozwiązaniu właśnie zmieniłem bibliotekę. Będę miał okazję zrobić to jeszcze raz. Wypróbuję twoje. – Manawasp

+0

Dzięki Iris! niektórzy z nas polegają na SO bardziej niż przechodząc przez dokumenty: P – Aukhan

Powiązane problemy