In che modo il browser Chrome decide quando inviare OPZIONI?

Question

Possiedo un'applicazione WebAPI AngularJS.

Per quanto posso capire la richiesta OPZIONI è costruita automaticamente dal browser.

POST http://localhost:3048/Token HTTP/1.1 
Host: localhost:3048 
Connection: keep-alive 
Content-Length: 78 
Accept: application/json, text/plain, */* 
Origin: http://localhost:2757 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 
Content-Type: application/x-www-form-urlencoded 
Referer: http://localhost:2757/Auth/login 
Accept-Encoding: gzip, deflate 
Accept-Language: en-US,en;q=0.8 

grant_type=password&username=xxx%40live.com&password=xxx 

Risposta:

HTTP/1.1 200 OK 
Cache-Control: no-cache 
Pragma: no-cache 
Content-Length: 971 
Content-Type: application/json;charset=UTF-8 
Expires: -1 
Server: Microsoft-IIS/8.0 
Access-Control-Allow-Origin: * 
Set-Cookie: .AspNet.Cookies=CpvxrR1gPFNs0vP8GAmcUt0EiKuEzLS1stLl-70O93wsipJkLUZuNdwC8tZc5M0o1ifoCjvnRXKjEBk3nLRbFlbldJLydW2BWonr5JmBjRjXZyKtcc29ggAVhZlc2E-3gGDlyoZLAa5Et8zrAokl8vsSoXmHnsjrxZw0VecB_Ry98Ln84UuKdeHlwSBnfaKKJfsN-u3Rsm6MoEfBO5aAFEekhVBWytrYDx5ks-iVok3TjJgaPc5ex53kp7qrtH3izbjT7HtnrsYYtcfPtmsxbCXBkX4ssCBthIl-NsN2wObyoEqHMpFEf1E9sB86PJhTCySEJoeUJ5u3juTnPlQnHsk1UTcO0tDb39g-_BD-I4FWS5GMwxLNtmut3Ynjir0GndwqsvpEsLls1Y4Pq7UuVCTn7DMO4seb64Sy8oEYkKZYk9tU4tsJuGD2CAIhdSc-lAmTAA78J5NOx23klkiuSe_SSiiZo5uRpas_1CFHjhi1c8ItEMpgeTsvgTkxafq5EOIWKPRxEHbCE8Dv106k5GlKK5BaH6z7ESg5BHPBvY8; path=/; HttpOnly 
X-SourceFiles: =?UTF-8?B?QzpcR1xhYmlsaXRlc3Qtc2VydmVyXFdlYlJvbGVcVG9rZW4=?= 
X-Powered-By: ASP.NET 
Date: Tue, 13 Jan 2015 04:54:55 GMT 

{"access_token":"TkJ2trqT .... 

Ora loggato

accedo quale non è altro che la rimozione del token e accedere nuovamente. Qualcosa accade che è diverso. Prima non inviava le OPZIONI, ma ora lo fa. C'è qualcosa che risulta da una precedente richiesta/risposta che potrebbe influenzare il browser ad agire in modo diverso la seconda volta che effettuo l'accesso?

OPTIONS http://localhost:3048/Token HTTP/1.1 
Host: localhost:3048 
Connection: keep-alive 
Access-Control-Request-Method: POST 
Origin: http://localhost:2757 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 
Access-Control-Request-Headers: accept, authorization, content-type 
Accept: */* 
Referer: http://localhost:2757/Auth/login 
Accept-Encoding: gzip, deflate, sdch 
Accept-Language: en-US,en;q=0.8 

Risposta:

HTTP/1.1 400 Bad Request 
Cache-Control: no-cache 
Pragma: no-cache 
Content-Length: 34 
Content-Type: application/json;charset=UTF-8 
Expires: -1 
Server: Microsoft-IIS/8.0 
X-SourceFiles: =?UTF-8?B?QzpcR1xhYmlsaXRlc3Qtc2VydmVyXFdlYlJvbGVcVG9rZW4=?= 
X-Powered-By: ASP.NET 
Date: Tue, 13 Jan 2015 04:56:32 GMT 

{"error":"unsupported_grant_type"} 

Se faccio un reset browser e ricarica della pagina, allora va indietro a come prima dove non invia OPZIONI la prima volta e io sono in grado di accedere

Probabilmente ho bisogno di cambiare qualcosa sul server in modo che gestisca le opzioni.

MA perché il mio browser (Chrome) non invia OPZIONI la prima volta?

Answer 1

Sia Chrome (o qualsiasi altro browser) invia una richiesta OPTIONS è esattamente specificato dal CORS specfication:

Quando il cross-origin request algoritmo è invocato, questi passaggi devono essere seguite:
...
2. Se le seguenti condizioni sono vere, seguire la simple cross-origin request algoritmo:

• il request method è un simple method e force preflight flag non è impostato.

• Ciascuna author request headers è un simple header o author request headers è vuota.

3.   In caso contrario, seguire la cross-origin request with preflight algoritmo.
Nota: le richieste cross-origine utilizzando un metodo che è simple con author request headers che non sono simple avrà un preflight request per garantire che la risorsa in grado di gestire queste intestazioni. (Analogamente alle richieste che utilizzano un metodo diverso da simple method.)

La richiesta OPTIONS contiene la seguente richiesta di intestazione:

Access-Control-Request-Headers: accept, authorization, content-type

Ciò significa che la vostra applicazione angolare ha inserito la non simpleAuthorization richiesta di intestazione, probabilmente come parte di uno schema di autenticazione. Le "intestazioni di richiesta autore" non semplici attivano la richiesta OPZIONI, come puoi vedere nella citazione precedente.

Per consentire la richiesta per avere successo, il server deve gestire la richiesta OPTIONS e rispondere con:

Access-Control-Allow-Origin: https://example.com 
Access-Control-Allow-Headers: authorization 

Per ulteriori informazioni su CORS, vedere https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS.

Answer 2

Al primo accesso è molto probabile impostare l'intestazione HTTP Authorization da qualche parte nella procedura di accesso. Dall'altro lato, hai dimenticato di rimuovere questa intestazione quando l'utente si disconnette.

Quando si tenta di accedere nuovamente, l'intestazione HTTP Authorization è ancora presente. Questo fa sì che il browser esegua una richiesta di verifica preliminare (vedere la spiegazione di Rob W: https://stackoverflow.com/a/27924344/548020. Considerando che si tenta di accedere con una password di tipo grant, non ha senso inviare un'intestazione Authorization, poiché ciò implica che si è già autorizzati (= loggato). voi fondamentalmente chiedendo al tuo back-end a voi il login e allo stesso tempo dire al vostro back-end che si sta già autorizzato (= clienti registrati).

Questo può essere risolto con una semplice rimuovendo l'intestazione Authorization HTTP quando l'utente si disconnette

Answer 3

È inoltre possibile pulire le intestazioni quando si effettua il login, prima di inviare la richiesta POST:.

delete $http.defaults.headers.common['Authorization'];