401 Fehler - JWT Token nicht gefunden mit fetch

Question

Ich bin neu zu reagieren, und vor allem auf Javascript. Ich benutze reagieren für eine Web-app gehostet auf localhost: 3000 mit node.js und symfony 2.8 für mein Backend, gehostet auf localhost: 80 mit Apache, die eine API mit Lexik und fos Benutzer gesichert. Vor dem Sichern der API funktioniert alles einwandfrei. Nach dem api Sicherung, bekomme ich einen 401-Fehler, wenn wie folgt verwendet holen:

let myToken = localStorage.getItem('auth_token') //token properly retrieved 
let myHeaders = new Headers(); 
myHeaders.append("Authorization", myToken) 
return fetch(
    pathToMyResource, 
    { 
     method: "post", 
     headers: myHeaders 
    } 
).then(do stuff with the answer) 

Das gibt mir die folgenden Fehler in dem Header der Antwort auf die Preflight-Anfrage:

Request URL:http://127.0.0.1/edsa-food_app_symfony_2.8/api/site/1/get 
Request Method:OPTIONS 
Status Code:401 Unauthorized 
Remote Address:127.0.0.1:80 
Referrer Policy:no-referrer-when-downgrade 

Und die Antwort:

{"code":401,"message":"JWT Token not found"} 

ich habe auch nur, weil ich nicht wirklich verstehen, wie das funktionieren soll, mit

credentials: 'include' 

Und

mode: 'no-cors' 

Aber war nicht mehr erfolgreich.

Wenn ich diese Anfrage mit php von localhost: 8000 erstellen und senden, funktioniert es perfekt. Ich verwende den folgenden Code ein:

$url = pathToMyResource 
$options = array(
    'http' => array(
     'header' => "Authorization: Bearer $token" 
     'method' => 'POST', 
    ) 
); 

$context = stream_context_create($options); 
$result = file_get_contents($url, false, $context); 
var_dump($result); 

Wenn ich gut verstehen, ist es nicht der Apache Fehler in Lexik JWT Token not found beschrieben werden kann: der Standard .htaccess an der Wurzel jeden symfony 2.8 Projektes umfasst:

RewriteEngine On 
RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$ 
RewriteRule ^(.*) - [E=BASE:%1] 

Ich überprüfte und mod_rewrite ist aktiviert.

Im Folgenden sind die Header wie in Chrome gemeldet:

**General** 
Request URL:http://127.0.0.1/edsa-food_app_symfony_2.8/api/site/1/get 
Request Method:OPTIONS 
Status Code:401 Unauthorized 
Remote Address:127.0.0.1:80 
Referrer Policy:no-referrer-when-downgrade 

**Response Headers** 
view source 
Access-Control-Allow-Origin:* 
Cache-Control:no-cache 
Connection:Keep-Alive 
Content-Length:44 
Content-Type:application/json 
Date:Tue, 08 Aug 2017 01:05:20 GMT 
Keep-Alive:timeout=5, max=100 
Server:Apache/2.4.18 (Win32) PHP/5.6.19 
WWW-Authenticate:Bearer 
X-Powered-By:PHP/5.6.19 

**Request Headers** 
view source 
Accept:*/* 
Accept-Encoding:gzip, deflate, br 
Accept-Language:en-GB,en;q=0.8,en-US;q=0.6,fr;q=0.4,zh-CN;q=0.2,zh;q=0.2,it;q=0.2 
Access-Control-Request-Headers:authorization 
Access-Control-Request-Method:POST 
Connection:keep-alive 
Host:127.0.0.1 
Origin:http://localhost:3000 
Referer:http://localhost:3000/service-worker.js 
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 

Und für die POST-Anfrage selbst:

**General** 
Request URL:http://127.0.0.1/edsa-food_app_symfony_2.8/api/site/1/get 
Referrer Policy:no-referrer-when-downgrade 

**Request Headers** 
Provisional headers are shown 
authorization:Bearer eyJhbGciOiJSUzI1NiJ9.eyJyb2xlcyI6WyJST0xFX1VTRVIiXSwidXNlcm5hbWUiOiJhbnRvaW5lIiwiaWF0IjoxNTAyMTM4ODUwLCJleHAiOjE1MDIyMjUyNTB9.wpWZZLf5wWjrU0-eAQUR0XiDTvf1jRtiJuGIHoYm7Yo4lGhOn-_bYuJIdv71ZUiuYfaaMxOW4xzXN3JjB9KfrWmXD4jqI6CnHFYZISGlYvAGJayD_z8CMIEdvrMXrbb6_nEc0CaB68BOf7wqJyoNatFKlepwmCHevsRtTIbhc_GviQf_U_Fw30ShtogIJBLqmVD4ex-j0_9QbblAIqNhc8c0thEFYtN7FVepLehCzBNCTNL8l-mxYEFTrUYLKwSt4lRahgTsv4Ozhxl300xz7BbdQEr3ph2i4ssVcvokpEO2C07QicWSwXFx1Vx-2a6XbkoeorTz_P7WstBzinMdv0etlIz2VYN_oUmHaxDu9jlsu90nZlL2Ea7Ak7dSJaNYzmB11yga_OSiWMpzWTjaqP3MLJuS1O5keHMbliERgnBJM_rsMZ-mkVSM8j4t31L1QJCfP0RW-Vfj3biYR1uYNfXwbbdqmIpn6b39qOCY9l4F99dK6R-PKq5ZeBHEfy-OpN39NFmaMQQX5gYCQ3TzVdeou6-hjpqRnNl8dc0HYzAl3fbU102JMefZNvCsIdcI6WDCiyWZO9Viy-z9REAVF4Pr9bLFpc-Q6Lqdj32lt1-yy6i75IOavrPqRilhRh2z_V7rP_DqahrLhFSDPPVg_gcqb8n31_6q3wtyzx16aJ4 
Origin:http://localhost:3000 
Referer:http://localhost:3000/restaurant 
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 

bin ich verloren.

Answer 1

Sie benötigen Backend zu konfigurieren, so dass es mit einem auf die Preflight reagiert 200 oder 204

können Sie in der Lage sein, dass dies, indem Sie Ihre Apache-Konfiguration an der Apache-Ebene zu behandeln:

RewriteEngine On 
RewriteCond %{REQUEST_METHOD} OPTIONS 
RewriteRule ^(.*)$ $1 [R=200,L] 

Aber wenn das nicht behoben ist dann müssen Sie weiter graben und herauszufinden, welcher Teil Ihres Backend-Systems Authentifizierung für OPTIONS Anforderungen erforderlich ist.

Der Grund ist, weil, was hier geschieht, ist dies:

1. Ihr Code teilt Ihren Browser sie will eine Anfrage mit dem Authorization Header senden.
2. Ihr Browser sagt, OK, Anfragen mit der Authorization Header erfordern, dass ich eine CORS Preflight OPTIONS, um sicherzustellen, dass der Server Anfragen mit diesem Header ermöglicht.
3. Ihr Browser sendet die OPTIONS Anfrage an den Server ohne Authorization Kopf -weil die ganze Zweck der OPTIONS überprüfen, ist, wenn es in Ordnung ist, dass zu senden.
4. Der Server sieht die OPTIONS Anfrage, aber anstatt darauf zu antworten, dass es Authorization in Anfragen erlaubt, lehnt es es mit einem 401 ab, da es diesen Header fehlt.
5. Ihr Browser erwartet eine 200 oder 204 Antwort für das CORS-Preflight, erhält aber stattdessen diese 401-Antwort. Ihr Browser stoppt also genau dort und versucht nie die POST Anfrage von Ihrem Code.