Połączenie międzydomenowe nie działa z SignalR PersistentConnection

Question

UWAGA: Ktoś jeszcze zadał to pytanie, ale usunął je, zanim mogłem opublikować odpowiedź. Ponieważ to pytanie dotyczy wielu problemów, z jakimi borykają się deweloperzy próbując uczynić SignalR pracą w różnych domenach, zdecydowałem się je powielić. Dodatkowo, już skończyłem pisać odpowiedź!

Używam serwera SignalR 1.0.1 w projekcie ASP.NET MVC .NET Framework 4. Mam inną aplikację ASP.NET na innej domenie (inny port localhost) próbując połączyć się za pośrednictwem klienta JavaScript. Mam to kiedy moja aplikacja próbuje połączyć:

XMLHttpRequest cannot load http://localhost:31865/api/negotiate?_=1363105027533. 
Origin http://localhost:64296 is not allowed by Access-Control-Allow-Origin. 

I już po wszelkie kroki, aby włączyć obsługę cross-domeny z SignalR - Czego mi brakuje?

• jQuery.support.cors = true;
• $.connection('http://localhost:31865/api', '', false, { jsonp: true, xdomain: true });
• RouteTable.Routes.MapHubs(new HubConfiguration { EnableCrossDomain = true });
• RouteTable.Routes.MapConnection<ApiConnection>("/api", "api");

Dodałem też następujące do Web.config w projekcie API:

<system.webServer> 
    <httpProtocol> 
    <customHeaders> 
     <add name="Access-Control-Allow-Origin" value="*" /> 
    </customHeaders> 
    </httpProtocol> 
</system.webServer> 

jestem u śpiewaj PersistentConnection dla mojego serwera SignalR, a nie dla koncentratorów.

Wszelkie pomysły?

Answer 1

MapHubs skonfiguruje punkt końcowy w/signalr do komunikacji ze wszystkimi klasami Hub. Ponieważ nie używasz koncentratorów, połączenie z MapHubs jest niepotrzebne. Wywołanie MapHubs również nie ma żadnego wpływu na konfigurację połączenia/api.

wezwanie do MapConnection powinien zostać zmieniony i otrzymuje następujące brzmienie:

RouteTable.Routes.MapConnection<ApiConnection>("api", "api", 
    new ConnectionConfiguration { EnableCrossDomain = true }); 

UWAGA: Drugi argument MapConnection jest URL. Pierwszym argumentem jest nazwa trasy. Model / jest zbędny, ale w obu przypadkach nie zaszkodzi.

• Ustawianie jQuery.support.cors = true; powinny TYLKO być zrobione "Aby włączyć żądań między domenami w środowiskach, które nie obsługują Cors jeszcze, ale nie pozwalają wnioski XHR cross-domain (PC gadżet, etc)" [1]. Nie dotyczy to żadnej wersji IE ani żadnej innej przeglądarki, którą znam. Jeśli przeglądarka nie obsługuje CORS, SignalR automatycznie powróci do JSONP , chyba że ustawisz dla ustawienia jQuery.support.cors na true.

  Jeśli tylko ustawiony na true ślepo, SignalR zakłada, że ​​środowisko nie obsługuje żądania XHR między domenami i nie automatycznie powróci do jsonp renderowania SignalR w stanie nawiązać połączenia między domenami, gdy działa w przeglądarkach, które naprawdę nie obsługują CORS.

• $.connection('http://localhost:31865/api', '', false, { jsonp: true, xdomain: true }); jest niepoprawny.Trzeba tylko trzeba

  var connection = $.connection('http://localhost:31865/api'); 
  

  xdomain nie jest opcją dla klienta SignalR JS, a jeśli naprawdę chcesz określić jsonp, należy to zrobić, kiedy start połączenie tak:

  connection.start({ jsonp: true}).done(function() { /* ... */ }); 
  

  Powinienem powtórzyć, że SignalR automatycznie zmieni się na cofnie się do JSONP, jeśli środowisko nie obsługuje CORS, więc nie powinno być określać tego op się. JSONP nie wymaga nagłówka Access-Control-Allow-Origin, ale zmusza SignalR do korzystania z jego najbardziej nieefektywnego transportu: długiego sondowania.

• Nie musisz konfigurować customHeaders w swoim pliku Web.config. SignalR ustawi nagłówek Access-Control-Allow-Origin w odpowiedziach SignalR automatycznie po ustawieniu EnableCrossDomain na true w Tobie ConnectionConfiguration.

Numer referencyjny https://github.com/SignalR/SignalR/wiki/QuickStart-Persistent-Connections w celu uzyskania dalszych porad dotyczących korzystania z PersistentConnections.