Jak uniknąć "ostrzeżenia o zawartości mieszanej" z signalR, w scenariuszu między domenami?

Question

Próbuję zbudować prototyp przeglądarki internetowej: < -> komunikację aplikacji Windows, używając SignalR.

Cel jest prosty: na każdym kliencie odbierającym kartę inteligentną jest uruchamiana aplikacja do obsługi tacy, która generuje wartość, która powinna zostać przekazana do aplikacji internetowej.

Zbudowałem samodzielnie hostowany koncentrator SignalR w aplikacji do obsługi podajników, a strona internetowa komunikuje się z nim pomyślnie.

Problem polega na tym, że aplikacja jest dostarczana za pośrednictwem protokołu HTTPS, a koncentrator signalR jest dostarczany za pośrednictwem klasycznego protokołu HTTP (na przykład http://localhost:8080) i zgodnie z oczekiwaniami najnowocześniejsza przeglądarka generuje ostrzeżenie o treści mieszanej i odmawia rozmowy z signalR.

Moje pytania są następujące:

1) Czy istnieje sposób, aby uniknąć mieszanej zawartości ostrzeżenie?

2) Czy warto zbudować samohostowany serwer http obsługujący HTTPS? A jeśli tak, czy przeglądarka porozmawia z klientem pod numerem https://localhost/ z własnym podpisem?

Dziękuję

Answer 1

Prosisz dwa pytania tutaj:

Unikaj mieszane ostrzeżenia treści w IE To proste: Przejdź do Narzędzia -> Opcje internetowe i wybierz kartę Zabezpieczenia. Upewnij się, że wybrana jest strefa Internet, a następnie kliknij przycisk Niestandardowy poziom . Przewiń w dół do pozycji Wyświetl zawartość mieszaną i ustaw ją na Włącz.

Należy pamiętać, że to ustawienie jest nie bez powodu. Zmiana wiąże się z ryzykiem bezpieczeństwa i dotyczy wszystkich odwiedzanych stron internetowych. Nie zaleca się poproszenia przyszłych użytkowników aplikacji o zmianę tego ustawienia. Jednak nadal jest to możliwe.

Wszystkie inne popularne przeglądarki umożliwiają również zmianę tego ustawienia.

Hosting serwera SSL z podpisem własnym certyfikatem Jest to z pewnością możliwe. Należy jednak pamiętać, że użytkownik napotka ostrzeżenia podobne do powyższych, a mianowicie ostrzeżenia "Niezaufane połączenie". Służą one do informowania użytkownika o certyfikacie, który nie został podpisany przez oficjalną jednostkę certyfikującą.

Tworzenie certyfikatu z podpisem własnym nie powinno być zbyt trudne (w rzeczywistości można nawet użyć tego samego certyfikatu na wielu komputerach. Jest to akceptowalna alternatywa dla używania niezaszyfrowanego protokołu HTTP). Zaletą tego jest to, że użytkownicy mogą jednorazowo potwierdzić wyjątek bezpieczeństwa i nie powinni się tym przejmować; nie wpłynie to również na bezpieczeństwo WWW podczas przeglądania innych stron niż localhost.