erreur 401 - Jeton JWT pas trouvé en utilisant chercher

Question

Je suis nouveau à réagir, et surtout à javascript. J'utilise rea pour une application web hébergée sur localhost: 3000 avec node.js et symfony 2.8 pour mon back end, hébergée sur localhost: 80 avec apache, qui expose une api sécurisée avec lexik et fos user. Avant de sécuriser l'API, tout fonctionne correctement. Après avoir obtenu l'api, je reçois une erreur 401 lorsque vous utilisez chercher comme suit:

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) 

Cela me donne l'erreur suivante dans les en-têtes de la réponse à la demande prévol:

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 

Et la réponse:

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

J'ai aussi vérifié, juste parce que je ne comprends pas vraiment comment cela est censé fonctionner, avec

credentials: 'include' 

Et

mode: 'no-cors' 

mais n'a pas plus de succès.

Lorsque je compile et envoie cette même requête en utilisant php de localhost: 8000, cela fonctionne parfaitement. J'utilise le code suivant:

$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); 

Si je comprends bien, il ne peut pas être l'erreur apache décrit dans Lexik JWT Token not found: le .htaccess par défaut à la racine de tout projet 2.8 symfony COMPREND:

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

J'ai vérifié et mod_rewrite est activé.

Voici les en-têtes comme indiqué dans Chrome:

**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 

Et pour la requête POST lui-même:

**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 

Je suis perdu.

Answer 1

Vous devez configurer votre back-end afin qu'il réponde au prévol avec 200 ou 204.

Vous pourriez être en mesure de gérer cela au niveau d'Apache en ajoutant votre votre config Apache ceci:

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

Mais si cela ne résout pas, alors vous devrez creuser plus loin et déterminer quelle partie de votre système dorsal est à l'origine de l'authentification pour les requêtes OPTIONS.

La raison est parce que ce qui se passe ici est la suivante:

1. Votre code indique votre navigateur, il veut envoyer une demande avec l'en-tête Authorization.
2. Votre navigateur affiche, OK, demandes avec l'entête Authorization m'obligent à faire un CORS preflight OPTIONS pour m'assurer que le serveur autorise les demandes avec cet en-tête.
3. Votre navigateur envoie la OPTIONS demande au serveur sans l'en-tête Authorization -Parce le but de la vérification OPTIONS est de voir s'il est OK pour l'envoyer.
4. Le serveur voit la demande OPTIONS mais au lieu de répondre à la demande d'une manière qui indique Authorization dans les demandes, il le rejette avec un 401 car il manque cet en-tête.
5. Votre navigateur s'attend à recevoir une réponse 200 ou 204 pour le contrôle en amont CORS, mais reçoit à la place cette réponse 401. Votre navigateur s'arrête donc là et n'essaie jamais la demande POST de votre code.