È possibile intercettare gli errori CORS?

Question

Questa domanda è correlata alla condivisione delle risorse tra le origini (CORS, http://www.w3.org / TR / cors / ).

Se si verifica un errore quando si effettua una richiesta CORS, Chrome (e anche altri browser AFAIK) registra un errore nella console degli errori.Un messaggio di esempio potrebbe essere simile a questo:

XMLHttpRequest non può caricare http://domain2.example.Origin http://domain1.example non è consentito da Access-Control-Allow-Origin.

Mi chiedo se esiste un modo per ricevere questo messaggio di errore a livello di codice?Ho provato a racchiudere la mia chiamata xhr.send() in try / catch, ho anche provato ad aggiungere un gestore di eventi onerror().Nessuno dei due riceve il messaggio di errore.

Answer 1

Vedi:

• http:// www .w3.org / TR / cors / # handling-a-response-to-a-cross-origin-request

... così come le note in XHR Livello 2 su CORS:

• http://www.w3.org/TR/XMLHttpRequest2/

Le informazioni vengono filtrate intenzionalmente.

Modifica molti mesi dopo: un commento di follow-up qui chiedeva "perché"; all'ancora nel primo collegamento mancavano alcuni caratteri, il che rendeva difficile vedere a quale parte del documento mi riferivo.

È una questione di sicurezza: un tentativo di evitare di esporre le informazioni nelle intestazioni HTTP che potrebbero essere sensibili. Il collegamento W3C su CORS dice:

I programmi utente devono filtrare tutte le intestazioni di risposta diverse da quelle che sono una semplice intestazione di risposta o il cui nome del campo è una corrispondenza ASCII senza distinzione tra maiuscole e minuscole per uno dei valori delle intestazioni Access-Control-Expose-Headers (se any), prima di esporre le intestazioni di risposta alle API definite nelle specifiche API CORS.

Quel passaggio include collegamenti per "semplice intestazione della risposta", che elenca Cache-Control, Content-Language, Content-Type, Expires, Last-Modified e Pragma. Quindi quelli vengono passati. La parte "Access-Control-Expose-Headers headers" consente al server remoto di esporre anche altre intestazioni elencandole lì. Vedere la documentazione del W3C per ulteriori informazioni.

Ricorda che hai un'origine - diciamo che è la pagina web che hai caricato nel browser, che esegue un po 'di JavaScript - e lo script sta facendo una richiesta a un'altra origine, cosa che normalmente non è consentita perché il malware può farlo cose brutte in quel modo. Quindi, il browser, che esegue lo script ed esegue le richieste HTTP per suo conto, funge da gatekeeper.

Il browser esamina la risposta da quel server "altra origine" e, se non sembra "prendere parte" a CORS - le intestazioni richieste mancano o sono malformate - allora siamo in una posizione di no fiducia. Non possiamo essere sicuri che lo script in esecuzione localmente stia agendo in buona fede, poiché sembra che stia tentando di contattare server che non si aspettano di essere contattati in questo modo. Il browser certamente non dovrebbe "far trapelare" alcuna informazione sensibile da quel server remoto semplicemente passando la sua intera risposta allo script senza filtrare - questo sarebbe fondamentalmente consentire una richiesta cross-origin, di sorta. Si creerebbe una vulnerabilità legata alla divulgazione di informazioni.

Questo può rendere difficile il debug, ma è un compromesso tra sicurezza e usabilità in cui, poiché "l'utente" è uno sviluppatore in questo contesto, alla sicurezza viene data una priorità significativa.