2011-11-24 16 views
9

Wygląda na to, że większość, jeśli nie wszystkie, punkty końcowe dostawcy OEmbed nie mają włączonego CORS. Oznacza to, że muszę użyć JSONP (dla tych, którzy go obsługują) lub przejść przez serwer proxy, aby użyć oEmbed.Dlaczego więcej OEmbed providerów nie umożliwia współużytkowania zasobów między domenami na ich punktach końcowych?

Istnieje korporacyjna polityka przeciwko korzystaniu z JSONP od dostawców zewnętrznych, ale nadal chcę korzystać z OEmbed w sposób czysto po stronie klienta (w przypadku niektórych dostawców, którym ufamy). Rozumiem, jakie konsekwencje dla bezpieczeństwa ma KONSUMENT z oEmbed i dlaczego mogą nie chcieć dopuszczać znaczników zewnętrznych bezpośrednio do swoich stron, ale dlaczego dostawcy mieliby to ograniczyć? Równie dobrze mogłem mieć luki XSS, jeśli zbudowałem serwer proxy i nie filtrowałem wyników.

+1

Yup. Chciałbym, żeby tak zrobili. Slideshare zapewnia interfejs API z wyłączonym CORS, co czyni go praktycznie bezużytecznym. – Jaseem

+0

Jaki jest sens posiadania go w pierwszej kolejności, jeśli inne witryny z linkami do zasobów dostawcy nie mogą z niego korzystać? Jeśli jest to tylko do użytku wewnętrznego, to nie wymieniaj siebie jako wspierającego na oEmbed.com, nie? – Gunchars

Odpowiedz

1

Po prostu zgadywanie:

Może to być związane z żądaniami preflight. Specyfikacja CORS (http://www.w3.org/TR/cors/#resource-preflight-requests) stwierdza, że ​​klient powinien wysłać dodatkowe żądanie OPTION w wielu przypadkach (w zasadzie dla czegoś spoza bardzo podstawowego GET lub POST) . Oznacza to, że po stronie serwera podwoisz liczbę przychodzących żądań, dodając CORS, a może dodatkowy ładunek będzie nie do przyjęcia.

+0

OEmbed używa "różnią się podstawowe GET" i jako takie żądanie będzie nadal wysyłane, po prostu zostanie odrzucone po stronie klienta. – Gunchars

Powiązane problemy