2016-01-15 6 views
5

mio CSS è ospitato su https://www.site1.com (si tratta di un dominio autenticato) e utilizza woff/ttf file che si trovano su https://media.site1.com (è anche autenticato - stessa auth di www). Per connettersi a questi siti, devo utilizzare un proxy autenticato.miei CSS cative file del font carico web WOFF situato su un altro https + autenticazione del server (CORS correlato)

Devo abilitare CORS per consentire il caricamento cross-domain, ma sembra che non possa caricare risorse da un altro dominio se questo dominio è di base autenticato E io uso un proxy autenticato.

ho aggiunto in Apache le seguenti direttive:

SetEnvIf Origin "^http(s)?://(.*)$" origin_is=$0 
Header set Access-Control-Allow-Origin %{origin_is}e env=origin_is 
Header set Access-Control-Allow-Credentials "true" 
Header set Access-Control-Allow-Headers "*" 

Dovrebbe consentire a tutti di origine, ma quando il CSS carica il file woff (tramite richiesta GET), ottengo:

Richiesta (solo le intestazioni interessanti):

GET file.woff HTTP/1.1 
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 
Host media.site1.com 
Origin https://www.site1.com 
Proxy-Authorization Basic XXX1234567 
Connection keep-alive 
Cache-Control max-age=0 

Response (un s visto da Firebug o HttpFox):

HTTP/1.0 401 Unauthorized 
WWW-Authenticate BASIC realm="Unspecified" 
Server BigIP 
Connection close 
Content-Length 0 

Se autenticare manualmente per media.site1.com prima di andare a www, il risultato è lo stesso. Sembra che il browser non invii credenziali di autenticazione di base al server "multimediale".

Sono presenti intestazioni aggiuntive che devo impostare per garantire che i file WOFF vengano caricati da una posizione diversa, con autenticazione di base e infine con un proxy autenticato dall'azienda?

risposta

3

Abbiamo appena incontrato la stessa situazione.

Secondo le specifiche del W3C, i caratteri collegati a file CSS deve essere caricato in modalità "anonimo": https://www.w3.org/TR/2013/CR-css-fonts-3-20131003/#font-fetching-requirements Quindi, in pratica il browser normalmente non inviare i cookie di autenticazione.

Il modo in cui ho capito, hai 2 opzioni:

  1. Disattivare l'autenticazione per i file dei font su https://media.site1.com
  2. Questo è un hack e non sono del tutto sicuro che funzionerà. Puoi provare a inviare una richiesta AJAX per caricare il carattere prima del file CSS, come descritto qui: https://css-tricks.com/preventing-the-performance-hit-from-custom-fonts/ Naturalmente, in questo articolo lo fanno per motivi di prestazioni, ma nonostante tutto, l'idea è di caricare il file del font separatamente, quindi quando il file CSS viene caricato, il browser lo preleva dalla sua cache. Potrebbe essere necessario aggiungere l'intestazione withCredentials nella chiamata AJAX, come descritto qui: https://stackoverflow.com/a/7190487 Inoltre, dato che di solito si caricano file CSS nella parte superiore della pagina e JavaScript nella parte inferiore, per impedire il caricamento del file CSS e l'emissione del file CSS. richieste non riuscite è necessario caricarlo dinamicamente sul callback di successo della chiamata AJAX.

So che la seconda soluzione sembra essere un problema, ma non ne ho trovata una migliore.

+0

Perché questo limite è stato introdotto solo con i caratteri Web? perchè non con css, js ecc.? –

+0

@ elad.chen Posso solo supporre che gli autori delle specifiche del W3C intendessero i font essere facilmente e liberamente caricabili da altri server, il che in un certo senso ha senso. – AsGoodAsItGets

Problemi correlati