2011-11-24 18 views
9

Sembra che la maggior parte, se non tutti, gli endpoint del provider oMed non abbiano CORS abilitato. Ciò significa che devo usare JSONP (per quelli che lo supportano) o passare attraverso un proxy del server solo per usare oEmbed.Perché non più provider oMed hanno abilitato la condivisione di risorse tra domini sui loro endpoint?

Esiste una politica aziendale contro l'utilizzo di JSONP da parte di provider di terze parti, ma voglio comunque sfruttare oMed in modo esclusivamente lato client (per determinati provider di cui ci fidiamo). Comprendo le implicazioni sulla sicurezza di un CONSUMER di oMed e perché potrebbero non voler consentire direttamente la marcatura di terze parti nelle loro pagine, ma perché i provider potrebbero limitarlo? Potrei altrettanto facilmente avere vulnerabilità XSS se ho creato un proxy server e non ho filtrato i risultati.

+1

Sì. Vorrei che lo facessero. Slideshare fornisce un'API con disabilitato CORS che lo rende praticamente inutile. – Jaseem

+0

Qual è il punto di averlo in primo luogo se altri siti che hanno collegamenti con le risorse del provider non possono usarlo? Se è solo per uso interno, non elencare come supporto su oEmbed.com, no? – Gunchars

risposta

1

solo indovinare:

Esso può essere correlato alle richieste di verifica preliminare. Le specifiche CORS (http://www.w3.org/TR/cors/#resource-preflight-requests) affermano che il client deve inviare una richiesta OPTION aggiuntiva in molti casi (in pratica, per qualsiasi cosa al di fuori di un GET o POST molto di base) . Significa che, sul lato server, raddoppierete le vostre richieste in arrivo solo fornendo CORS e forse il carico aggiuntivo sarebbe inaccettabile.

+0

OEmbed utilizza "varia basic GET" e in quanto tale la richiesta verrà comunque inviata, sarà solo rifiutata dal lato client. – Gunchars

Problemi correlati