Podany schemat URI „https” jest nieprawidłowy; oczekiwany „http”. Nazwa parametru: via

Usiłuję utworzyć usługę WCF za pomocą basicHttpBinding do użycia przez https. Oto mój web.config:

<!-- language: xml -->
<service behaviorConfiguration="MyServices.PingResultServiceBehavior"
         name="MyServices.PingResultService">
    <endpoint address="" 
              binding="basicHttpBinding" 
              bindingConfiguration="defaultBasicHttpBinding"
              contract="MyServices.IPingResultService">
        <identity>
            <dns value="localhost" />
        </identity>
    </endpoint>
    <endpoint address="mex" 
              binding="mexHttpBinding" 
              contract="IMetadataExchange" />
</service>
...

<bindings>
  <basicHttpBinding>
    <binding name="defaultBasicHttpBinding">
      <security mode="Transport">
        <transport clientCredentialType="None"/>
      </security>
    </binding>
  </basicHttpBinding>
</bindings>
...
<behaviors>
  <serviceBehaviors>
    <behavior name="MyServices.UpdateServiceBehavior">
      <serviceMetadata httpsGetEnabled="true" />
      <serviceDebug includeExceptionDetailInFaults="true" />
    </behavior>
  </serviceBehaviors>
</behaviors>

Łączę się za pomocą WCFStorm, który jest w stanie poprawnie pobrać wszystkie metadane, ale kiedy wywołam rzeczywistą metodę, otrzymuję:

Podany schemat URI „https” jest nieprawidłowy; oczekiwany „http”. Nazwa parametru: via

Spróbuj dodać poświadczenia wiadomości do pliku app.config, np .:

<bindings> 
<basicHttpBinding> 
<binding name="defaultBasicHttpBinding"> 
  <security mode="Transport"> 
    <transport clientCredentialType="None" proxyCredentialType="None" realm=""/> 
    <message clientCredentialType="Certificate" algorithmSuite="Default" />
  </security> 
</binding> 
</basicHttpBinding> 
</bindings> 

Dodając to jako odpowiedź, tylko dlatego, że nie możesz zrobić zbyt wiele wymyślnego formatowania w komentarzach.
Miałem ten sam problem, z tym wyjątkiem, że tworzyłem i wiązałem mojego klienta usług internetowych całkowicie kodem.
Powodem jest to, że DLL był ładowany do systemu, co zabraniało używania plików konfiguracyjnych.

Oto kod, który musiał zostać zaktualizowany, aby komunikować się przez SSL ...

Public Function GetWebserviceClient() As WebWorker.workerSoapClient
    Dim binding = New BasicHttpBinding()
    binding.Name = "WebWorkerSoap"
    binding.CloseTimeout = TimeSpan.FromMinutes(1)
    binding.OpenTimeout = TimeSpan.FromMinutes(1)
    binding.ReceiveTimeout = TimeSpan.FromMinutes(10)
    binding.SendTimeout = TimeSpan.FromMinutes(1)

    '// HERE'S THE IMPORTANT BIT FOR SSL
    binding.Security.Mode = BasicHttpSecurityMode.Transport

    Dim endpoint = New EndpointAddress("https://myurl/worker.asmx")

    Return New WebWorker.workerSoapClient(binding, endpoint)
End Function

Zmień z

<security mode="None">

do

<security mode="Transport">

w pliku web.config. Ta zmiana pozwoli Ci używać https zamiast http

Czy używasz tego na Cassini (vs serwer dev) lub w IIS z zainstalowanym certyfikatem? W przeszłości miałem problemy z podłączeniem bezpiecznych punktów końcowych na serwerze deweloperskim.

Oto konfiguracja wiązania, która działała dla mnie w przeszłości. Zamiast basicHttpBindingtego używa wsHttpBinding. Nie wiem, czy to dla ciebie problem.

<!-- Binding settings for HTTPS endpoint -->
<binding name="WsSecured">
    <security mode="Transport">
        <transport clientCredentialType="None" />
        <message clientCredentialType="None"
            negotiateServiceCredential="false"
            establishSecurityContext="false" />
    </security>
</binding>

i punkt końcowy

<endpoint address="..." binding="wsHttpBinding"
    bindingConfiguration="WsSecured" contract="IYourContract" />

Upewnij się również, że zmieniłeś konfigurację klienta, aby włączyć zabezpieczenia transportu.

Miałem ten sam wyjątek w custom bindingscenariuszu. Każdy, kto stosuje to podejście, może to również sprawdzić.

W rzeczywistości dodawałem odwołanie do usługi z local WSDL pliku. Został dodany pomyślnie i wymagane plik niestandardowy został dodany do pliku konfiguracyjnego. Jednak faktyczną usługą była https; nie http. Zmieniłem więc element httpTransport as httpsTransport. To rozwiązało problem

<system.serviceModel>
<bindings>

  <customBinding>
    <binding name="MyBindingConfig">

      <textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"
        messageVersion="Soap11" writeEncoding="utf-8">
        <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
          maxBytesPerRead="4096" maxNameTableCharCount="16384" />
      </textMessageEncoding>

      <!--Manually changed httpTransport to httpsTransport-->
      <httpsTransport manualAddressing="false" maxBufferPoolSize="524288"
        maxReceivedMessageSize="65536" allowCookies="false" authenticationScheme="Anonymous"
        bypassProxyOnLocal="false" 
        decompressionEnabled="true" hostNameComparisonMode="StrongWildcard"
        keepAliveEnabled="true" maxBufferSize="65536" 
        proxyAuthenticationScheme="Anonymous"
        realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false"
        useDefaultWebProxy="true" />
    </binding>
  </customBinding>

</bindings>

<client>
  <endpoint address="https://mainservices-certint.mycompany.com/Services/HRTest"
    binding="customBinding" bindingConfiguration="MyBindingConfig"
    contract="HRTest.TestWebserviceManagerImpl" name="TestWebserviceManagerImpl" />
</client>


</system.serviceModel>

Bibliografia

1. WCF z niestandardowym wiązaniem na http i https

Miałem DOKŁADNIE ten sam problem co OP. Moja konfiguracja i sytuacja były identyczne. W końcu zawęziłem to do problemu w WCFStorm po utworzeniu odwołania do usługi w projekcie testowym w Visual Studio i potwierdzeniu, że usługa działa. W Storm musisz kliknąć opcję ustawień „Konfiguracja” (NIE „Konfiguracja klienta”). Po kliknięciu na to kliknij kartę „Bezpieczeństwo” w wyskakującym oknie dialogowym. Upewnij się, że „Typ uwierzytelnienia” jest ustawiony na „Brak” (ustawienie domyślne to „Uwierzytelnianie systemu Windows”). Presto, to działa! Zawsze testuję swoje metody w WCFStorm, gdy je buduję, ale nigdy nie próbowałem używać go do łączenia się z tą, która została już skonfigurowana na SSL. Mam nadzieję, że to komuś pomoże!

Natknąłem się na ten sam problem, oto jak moje rozwiązanie okazało się na końcu:

        <basicHttpsBinding>
            <binding name="VerificationServicesPasswordBinding">
              <security mode="Transport">
              </security>
            </binding>
            <binding name="VerificationServicesPasswordBinding1" />
        </basicHttpsBinding>

Zasadniczo zamieniłem każde wystąpienie HTTP na Https. Możesz spróbować dodać oba z nich, jeśli wolisz.

Jeśli zrobisz to programowo, a nie w pliku web.config:

new WebHttpBinding(WebHttpSecurityMode.Transport)

Warto pamiętać, że pliki konfiguracyjne można podzielić na pliki pomocnicze, aby ułatwić zmiany konfiguracji na różnych serwerach (dev / demo / produkcja itp.), Bez konieczności ponownej kompilacji kodu / aplikacji itp. Na przykład używamy ich, aby umożliwić inżynierom na miejscu wprowadzaj zmiany punktu końcowego bez faktycznego dotykania „prawdziwych” plików.

Pierwszym krokiem jest przeniesienie sekcji powiązań poza WPF App.Config do osobnego pliku.

Sekcja zachowań jest ustawiona tak, aby zezwalała zarówno na http, jak i https (nie wydaje się mieć wpływu na aplikację, jeśli oba są dozwolone)

<serviceMetadata httpsGetEnabled="true" httpGetEnabled="true" />

I przenosimy sekcję powiązań do własnego pliku;

 <bindings configSource="Bindings.config" /> 

W pliku bindings.config przełączamy zabezpieczenia w oparciu o protokół

  <!-- None = http:// -->
  <!-- Transport = https:// -->
  <security mode="None" >

Teraz inżynierowie na miejscu muszą jedynie zmienić plik Bindings.Config i Client.Config, w którym przechowujemy rzeczywisty adres URL dla każdego punktu końcowego.

W ten sposób możemy zmienić punkt końcowy z http na https iz powrotem, aby przetestować aplikację bez konieczności zmiany kodu.

Mam nadzieję że to pomoże.

Aby ponownie zdefiniować pytanie w PO:

Łączę się [z usługą WCF] za pomocą WCFStorm, który jest w stanie poprawnie pobrać wszystkie metadane, ale kiedy wywołuję rzeczywistą metodę, otrzymuję:

Podany schemat URI „https” jest nieprawidłowy; oczekiwany „http”. Nazwa parametru: via

Samouczki WCFStorm rozwiązują ten problem w pracy z IIS i SSL .

Ich rozwiązanie działało dla mnie:

1. Aby naprawić błąd, wygeneruj konfigurację klienta pasującą do konfiguracji usługi wcf. Najłatwiej to zrobić za pomocą Visual Studio.

   • Otwórz Visual Studio i dodaj odwołanie do usługi. VS wygeneruje plik app.config, który pasuje do usługi

   • Zmodyfikuj plik app.config, aby mógł być odczytany przez WCFStorm. Zobacz Ładowanie plików App.config klienta . Upewnij się, że atrybuty punktu końcowego / @ i kontraktu punktu końcowego / @ odpowiadają wartościom w wcfstorm.

2. Załaduj zmodyfikowany plik app.config do WCFStorm [za pomocą przycisku paska narzędzi konfiguracji klienta].

3. Wywołaj metodę Tym razem wywołanie metody nie zakończy się niepowodzeniem

Ostatni punkt punktu w pozycji (1) oznacza usunięcie prefiksu przestrzeni nazw, który VS poprzedza atrybutem kontraktu punktu końcowego, domyślnie „ServiceReference1”

<endpoint ... contract="ServiceReference1.ListsService" ... />

więc w app.config, który ładujesz do WCFStorm, który chcesz dla ListsService:

<endpoint ... contract="ListsService" ... />

Potrzebowałem następujących powiązań, aby mój działał:

        <binding name="SI_PurchaseRequisition_ISBindingSSL">
          <security mode="Transport">
            <transport clientCredentialType="Basic" proxyCredentialType="None" realm="" />
          </security>
        </binding>

wsHttpBinding jest problemem, ponieważ silverlight go nie obsługuje!