Więc JSONP czy CORS? [Zamknięte]

Moje WebAPI zostało wdrożone w środowisku intranetowym . Oznacza to, że bezpieczeństwo nie było moim zmartwieniem.

Wydaje się, że CORS jest znacznie bardziej przyjazny dla klienta i łatwiejszy do wdrożenia .

Jakieś inne obawy, które mogłem przeoczyć?

To dość szerokie pytanie, które może uzasadniać istnienie wiki. Jest też sporo w Google na temat tych dwóch, ale myślę, że mogę trafić w kilka kluczowych punktów.

• Jeśli potrzebujesz interfejsu Ajax tylko do odczytu na swoich serwerach i musisz obsługiwać IE <= 9, Opera <12 lub Firefox <3.5 lub różne inne starsze lub niejasne przeglądarki, CORS jest niedostępny, użyj JSONP. IE8 i IE9 obsługują CORS, ale mają problemy, zobacz link w pierwszym komentarzu poniżej.
• Z drugiej strony, jeśli twoje internetowe API jest do odczytu / zapisu (np. Pełny REST lub tylko POST / GET) zamiast tylko do odczytu (tj. GET), JSONP nie działa. Użyj CORS. JSONP jest z natury tylko do odczytu.

Jeśli żadna z tych rzeczy nie jest problemem, wybrałbym to, co jest dla Ciebie najłatwiejsze lub najbardziej znane. Jeśli to przypadek, wypróbuj CORS, ponieważ jest to bardziej „nowoczesne” rozwiązanie, a JSONP to bardziej hack, zamieniający dane w skrypty, aby ominąć ograniczenia międzydomenowe. CORS wymaga jednak zazwyczaj większej konfiguracji po stronie serwera.

Jeśli używasz jQuery, nie jestem pewien, skąd przyszedł ci do głowy pomysł, że CORS jest „ znacznie bardziej przyjazny dla klienta i łatwiejszy do wdrożenia ”. Zobacz https://gist.github.com/3131951 . jQuery wyodrębnia szczegóły JsonP, a CORS może być w rzeczywistości nieco trudny do zaimplementowania po stronie serwera, w zależności od używanej technologii.

Niedawno opracowałem aplikację internetową, używając jquery i backbone.js, która czyta z różnych usług internetowych międzydomenowych, które kontrolujemy, i ostatecznie użyłem Json-P zamiast CORS, ponieważ musimy obsługiwać IE7 i było to trochę prostsze na po stronie serwera (uruchamiamy Django w / DjangoRestFramework) i praktycznie to samo z jquery po stronie klienta.

Jesteś całkiem na miejscu. Jeśli nie musisz obsługiwać starszych przeglądarek (wydanych ponad 6 lat temu), zdecydowanie wybrałbym CORS.

CORS jest łatwiejszy do zaimplementowania, ponieważ jeśli Twój interfejs API nie obsługuje jeszcze JSONP lub CORS, łatwiej jest po prostu dodać kilka statycznych nagłówków niż modyfikować treść odpowiedzi.

Łatwiej jest również buforować żądania za pomocą CORS. Każde żądanie JSONP musi być dynamiczne, nawet z zawartością memcached.

JSONP jest nadal tagiem skryptu, więc bez względu na to, co spowoduje pewien poziom zachowania synchronicznego. CORS nie będzie.

JSONP może być tylko GET. Podobnie jak w przypadku CORS, możesz użyć dowolnej metody.

Wreszcie, jeśli używasz jQuery v1.x , weź pod uwagę, że errori complete(lub lepiej faili always) programy obsługi nadal nie są wywoływane dla żądań JSONP w niektórych typowych sytuacjach (np. Błędy sieciowe). Jasne, istnieją obejścia (ustawienie limitu czasu, wtyczka jQuery-JSONP), ale CORS wydaje mi się mniej irytujący, zwłaszcza gdy żądania międzydomenowe pochodzą tylko z urządzeń mobilnych (np. Aplikacje hybrydowe), więc nie potrzebujesz obsługi pechowych przeglądarek.

Według Spring Documentation, JSONP to hack, a nie właściwe rozwiązanie Cross Origin Resource Sharing. Jeśli więc bezpieczeństwo nie jest Twoim problemem, po prostu sprawdź pochodzenie domeny na swoim serwerze i dodaj nagłówek Access-Control-Allow-Origin Response.

Nasz internetowy interfejs API nie działał w przeglądarce Safari (iOS 9.1) z uwierzytelnianiem systemu Windows. To działało z Safari + iOS 8.4. Kiedy przeszliśmy na JSONP, Safari znów zaczęło działać. Sprawdź to łącze, aby uzyskać więcej informacji.