2010-03-02 10 views
7

Podobne do ograniczenia serwera WWW Visual Studio rozwoju, że to tylko serwery na localhost, mam wdrożenie usługi WCF, który jest potrzebny tylko na localhost.Konfigurowanie WCF do słuchania tylko LOCALHOST

Nie miałbym nic przeciwko innym komputerom mającym dostęp, z wyjątkiem tego, że Zapora systemu Windows monituje o zezwolenie programowi na nasłuchiwanie na zewnętrznej karcie sieciowej. Ponieważ jest to potrzebne tylko wewnętrznie, wolałbym ograniczyć konfigurację po stronie serwera WCF, aby nie zadziałał wykrywacz zapory.

Czy binding.HostNameComparisonMode = HostNameComparisonMode.Exact jest właściwym rozwiązaniem? Nie rozumiem, jak to wystarczy.

====

jak Cassini, to realizacja usługi jest stand-in dla czegoś innego, który nie wymaga komunikacji sieciowej. Klient może zostać skonfigurowany tak, aby łączył się z rzeczywistym serwerem lub fałszywą implementacją działającą na localhost.

Odpowiedz

0

To zależy od tego, jak go hostujesz. Jeśli jesteś w IIS7 lub WAS, to WCF używa trybu dopasowywania IIS. W przeciwnym razie, jeśli użyjesz HostNameComparisonMode.Exact, wtedy tak, nazwa hosta zawsze będzie kluczowym czynnikiem dopasowania. Jeśli nazwa hosta nie jest zgodna, wysyłanie zazwyczaj kończy się niepowodzeniem.

Należy zauważyć, że dokładny nie jest w 100% idealnie dokładny ... nadal pozwala na pewne zmiany w nazwie hosta. Jeśli masz zarówno nazwę hosta NetBios, jak i pełną nazwę DNS, dopasowanie będzie nadal występować, ponieważ WCF traktuje te dwa jako jedno i to samo.

System.ServiceModel.BasicHttpBinding.HostNameComparisonmode

+0

Próbowałem wiązania.HostNameComparisonMode = HostNameComparisonMode.Exact ponownie i to nie działa. Po wyczyszczeniu powiązanych reguł zapory systemu Windows zapora ponownie wyświetla monit, aby zezwolić na to. –

+0

Dodałem też 'nowy Uri (" net.tcp: // localhost ")' jako adres bazowy do konstruktora ServiceHost –

+0

Wygląda na to, że zapora ogniowa wyświetli monit niezależnie od tego, czy jest to host pętli zwrotnej, czy też nie. Nie jestem pewien, czy jest coś, co można z tym zrobić, poza używaniem potoków nazwanych. – jrista

6

Myślę, że zbliża się jej w niewłaściwy sposób. Powinieneś używać nazwanego powiązania potoku, które powinno obsługiwać dowolny wzorzec wymiany komunikatów, który jest używany (obsługuje reakcje żądanie-odpowiedź, a także te same tryby współbieżności i stanu sesji, które obsługuje WS).

Z odcinka MSDN zatytułowany "Choosing a Transport" (kopalnia nacisk):

kiedy użyć nazwanego potoku Transportu

Nazwany potok jest obiekt w systemie Windows jądra systemu operacyjnego , takie jako sekcja pamięci współużytkowanej, która może być używana do procesów w procesach . Nazwana rura o nazwie ma nazwę i może być używana do jednokierunkowej lub dupleksowej komunikacji między procesami na jednym komputerze.

Gdy wymagana jest komunikacja między różnymi aplikacjami WCF na pojedynczy komputer, a chcesz uniknąć komunikacji z innego maszynie, a następnie za pomocą nazwanych potoków transport. Dodatkowe ograniczenie polega na tym, że procesy uruchamiane z pulpitu zdalnego Windows mogą być ograniczone do tej samej sesji pulpitu zdalnego Windows , chyba że mają podwyższone uprawnienia .

To spełnia Twoje dokładne wymagania i nie może być więcej niż zmianą konfiguracji.

+0

Uzgodnione; "localhost only" to naprawdę "komunikacja międzyprocesowa", a nazwane potoki są najlepsze. – Randolpho

+0

Przepraszam - wyjaśniam: Podobnie jak w przypadku Cassini, ta implementacja usługi jest stand-inem dla czegoś innego, co NIE wymaga komunikacji sieciowej. Klient może zostać skonfigurowany tak, aby łączył się z rzeczywistym serwerem lub fałszywą implementacją działającą na localhost. –

+0

@Jason: Jeśli klient może zostać skonfigurowany, dlaczego nie skonfigurować go tak, aby używał punktu końcowego nazwanej rury, a nie punktu końcowego HTTP? Jak WCF jest zdolny do obu, a wywołanie usługi za pośrednictwem potoku vs http jest takie samo dla WCF ... po co zawracać sobie głowę czymkolwiek innym? – jrista