È ansible intrappolare errori CORS?

Questa domanda è correlata a Cross-Origin Resource Sharing (CORS, http://www.w3.org/TR/cors/ ).

Se si verifica un errore durante la richiesta CORS, Chrome (e altri browser AFAIK) registra un errore nella console degli errori. Un messaggio di esempio può apparire come questo:

XMLHttpRequest non può caricare http://domain2.example . L’origine http://domain1.example non è consentita da Access-Control-Allow-Origin.

Mi chiedo se c’è un modo per ottenere 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.

Vedere:

… così come le note in XHR livello 2 su CORS:

Le informazioni sono filtrate intenzionalmente.

Modifica molti mesi dopo: un commento di follow-up qui chiesto “perché”; l’ancora nel primo collegamento mancava alcuni caratteri che rendevano difficile vedere quale parte del documento mi riferissi a.

È una cosa 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 un’intestazione di risposta semplice o di cui il nome del campo è una corrispondenza senza distinzione tra maiuscole e minuscole ASCII per uno dei valori delle intestazioni di Access-Control-Expose-Headers (se presenti), prima di esporre le intestazioni di risposta alle API definite nelle specifiche API CORS.

Questo passaggio include collegamenti per “intestazione di risposta semplice”, che elenca Controllo della cache, Lingua del contenuto, Tipo di contenuto, Scadenza, Ultima modifica e Pragma. Quindi quelli sono passati. La parte “Intestazioni di Access-Control-Expose-Headers” consente al server remoto di esporre anche altre intestazioni inserendole nell’elenco. Consultare la documentazione del W3C per ulteriori informazioni.

Ricorda che hai una origine – diciamo che è la pagina web che hai caricato nel tuo browser, con qualche po ‘di JavaScript – e lo script sta facendo una richiesta a un’altra origine, che normalmente non è permessa perché il malware può fare cose cattive che modo. Quindi, il browser, eseguendo lo script ed eseguendo le richieste HTTP per suo conto, funge da gatekeeper.

Il browser esamina la risposta da quel server di “altra origine” e, se non sembra che “partecipi” a CORS – le intestazioni richieste mancano o sono malformate – quindi non ci si può fidare. Non possiamo essere sicuri che lo script eseguito localmente funzioni in buona fede, poiché sembra che stia cercando di contattare server che non si aspettano di essere contattati in questo modo. Il browser certamente non dovrebbe “filtrare” alcuna informazione sensibile da quel server remoto semplicemente passando la sua intera risposta allo script senza filtrare – che sostanzialmente consentirebbe una richiesta di origine incrociata, di sorta. Si presenterebbe una vulnerabilità legata alla divulgazione di informazioni.

Ciò può rendere difficile il debug, ma è un compromesso tra sicurezza e usabilità in cui, dal momento che l’utente è uno sviluppatore in questo contesto, la sicurezza ha una priorità significativa.