Наведена схема URI "https" недійсна; очікуваний "http". Назва параметра: через


281

Я намагаюся зробити сервіс WCF через basicHttpBinding, який буде використовуватися на https. Ось мій 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>

Я підключаюсь за допомогою WCFStorm, який здатний належним чином отримати всі метадані, але коли я зателефонував у фактичний метод, я отримую:

Наведена схема URI "https" недійсна; очікуваний "http". Назва параметра: через


4
Німецькою мовою повідомлення про помилку звучить " Das bereitgestellte URI-Schema" https "ist ungültig; erwartet wurde" http ". Ім'я параметра: через ", якщо хтось це гуглить.
Уве

Відповіді:


240

Спробуйте додати облікові дані повідомлень у програму app.config, наприклад:

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

35
Дякую за таку відповідь в рамках ОП; У мене виникла та сама проблема, і змінити режим тегу <security> з типового значення "None" на "Transport" виправлено це.
Отіс

1
За винятком блоку <message>, який IIS6 чомусь було відхилено, це спрацювало добре.
Кріс Чубб

4
скопіював ту саму конфігурацію в мій проект, але це нічого не дає ефекту. Я пропустив щось додати?

1
Дуже дякую. Я спробував декілька рішень, знайдених в Інтернеті, але жодне з них не працювало. Цей був ідеальний.
aspnetdeveloper

59

Додавши це як відповідь, тільки тому, що ви не можете зробити дуже фантазійне форматування в коментарях.
У мене була та сама проблема, за винятком того, що я створював і прив’язував свого клієнта веб-служб повністю до коду.
Причина в тому, що DLL завантажувалася в систему, яка забороняла використовувати файли конфігурацій.

Ось код, як його потрібно було оновити для спілкування через 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

Як ви створили заняття для свого веб-сервісу?
kaiyaq

це працює! У мене була така ж проблема в моєму C #. Просто скопіюйте пасту і вирішіть проблему.
користувач3417479

@kaiyaq - Я все ще можу підключитися до послуги штрафу для розробки зі всіма стандартними матеріалами, дозволяючи VS створювати для мене класи, які потім збираються в DLL. Просто під час виконання я не можу завантажити конфігураційний файл із усією інформацією про з'єднання.
ейдилон

BasicHttpBinding присутній за допомогою System.ServiceModel; Майбутні читачі FYI.
DLeh

38

Змінити з

<security mode="None">

до

<security mode="Transport">

у вашому файлі web.config. Ця зміна дозволить вам використовувати https замість http


30

Ви запускаєте це на Cassini (проти сервера dev) або на IIS із встановленим сертифікатом? У мене були проблеми, які намагалися підключити захищені кінцеві точки на веб-сервері розробників.

Ось конфігурація прив’язки, яка працювала для мене в минулому. Замість basicHttpBindingцього використовується wsHttpBinding. Я не знаю, чи це проблема для вас.

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

і кінцева точка

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

Також переконайтеся, що ви змінили конфігурацію клієнта, щоб увімкнути безпеку транспорту.


1
локальний IIS 7 із встановленим сертифікатом cert
isg

13
"Також переконайтеся, що ви змінили конфігурацію клієнта, щоб увімкнути безпеку транспорту." -- Хороша порада. Занадто легко не помітити і WCF не дасть підказки у своїх помилках.
Люк Пуплетт

не дійсні переговориСервісСвідки та встановленняSecurityContext
Kiquenet

20

У мене був такий самий виняток у custom bindingсценарії. Кожен, хто використовує такий підхід, може також перевірити це.

Я фактично додавав посилання на службу з local WSDL файлу. Додано успішно, і до конфігураційного файлу було додано необхідне спеціальне прив'язування. Однак фактична послуга була https; не http. Тому я змінив елемент httpTransport як httpsTransport. Це вирішило проблему

<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>

Список літератури

  1. WCF з власною прив'язкою як на http, так і на https

19

Я мав ТОЧНЕ те саме питання, що і ОП. Моя конфігурація та ситуація були однаковими. Нарешті я звузив це питання до WCFStorm після створення посилання на службу в тестовому проекті в Visual Studio і підтвердження того, що служба працює. У штормі вам потрібно натиснути на параметр "Налаштувати" налаштування (НЕ "Конфігурація клієнта"). Після натискання на це натисніть на вкладку "Захист" у діалоговому вікні, що з'явиться. Переконайтесь, що для "Тип аутентифікації" встановлено значення "Ні" (за замовчуванням - "Автентифікація Windows"). Престо, це працює! Я завжди перевіряю свої методи в WCFStorm, коли будую їх, але ніколи не намагався використовувати його для підключення до того, який вже був налаштований на SSL. Сподіваюся, це комусь допоможе!


У мене була така сама проблема, але у мене був неправильний пароль, використовуючи "Ідентифікація користувача / пароля". Виявляється, що якщо ви зміните свій пароль, вам потрібно натиснути URL-адресу послуги та кнопку "Оновити" на панелі інструментів, щоб її взяти.
Райан Шиллінгтон

12

Зустрічався з тим самим питанням, ось як виявилося моє рішення наприкінці:

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

Я в основному замінив кожне виникнення Http Https. Ви можете спробувати додати обидва з них, якщо хочете.


5
Слід зазначити, що basicHttpsBinding на 4.5 і новіший.
Джагд

7

Якщо ви робите це програмно, а не в web.config:

new WebHttpBinding(WebHttpSecurityMode.Transport)

Чудово. Я завжди ненавидів файли .exe.config і роблю все за кодом. Це вирішило мою проблему.
nivs1978

4

Добре пам’ятати, що конфігураційні файли можна розділити на вторинні файли, щоб полегшити зміни конфігурації на різних серверах (dev / demo / production тощо), без необхідності перекомпілювати код / ​​додаток тощо. Наприклад, ми використовуємо їх, щоб дозволити інженерам на місці вносити зміни в кінцевій точці, не торкаючись фактичних файлів.

Перший крок - перемістити розділ прив’язок із WPF App.Config у власний окремий файл.

Розділ поведінки налаштовано так, щоб дозволити як http, так і https (схоже, це не вплине на додаток, якщо дозволено обидва)

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

І ми переміщуємо розділ прив’язок до власного файлу;

 <bindings configSource="Bindings.config" /> 

У файлі bindings.config ми перемикаємо захист на основі протоколу

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

Тепер інженерам на сайті потрібно лише змінити файл Bindings.Config та Client.Config, де ми зберігаємо фактичну URL-адресу для кожної кінцевої точки.

Таким чином ми можемо змінити кінцеву точку з http на https та знову повернути тест на додаток, не змінюючи жодного коду.

Сподіваюсь, це допомагає.


2

Щоб повторно обмежити питання в ОП:

Я підключаюсь [до сервісу WCF] за допомогою WCFStorm, який здатний належним чином отримати всі метадані, але коли я зателефонував у фактичний метод, я отримую:

Наведена схема URI "https" недійсна; очікуваний "http". Назва параметра: через

Підручники WCFStorm вирішують це питання в роботі з IIS та SSL .

Їх рішення працювало на мене:

  1. Щоб виправити помилку, створіть конфігурацію клієнта, яка відповідає конфігурації послуги wcf. Найпростіший спосіб зробити це за допомогою Visual Studio.

    • Відкрийте Visual Studio і додайте посилання на службу. VS генерує файл app.config, який відповідає службі

    • Відредагуйте файл app.config так, щоб його можна було прочитати WCFStorm. Будь ласка, дивіться Завантаження файлів Client App.config . Переконайтесь, що атрибути кінцевої точки / @ та кінцевої точки / @ контракту відповідають значенням у wcfstorm.

  2. Завантажте змінену програму app.config у WCFStorm [за допомогою кнопки Toobar Client Config].

  3. Викликати метод. Цього разу виклик методу більше не вийде з ладу

Пункт (1) останньої кулі на ділі означає видалити префікс простору імен, який VS надає атрибуту контракту на кінцеву точку, за замовчуванням "ServiceReference1"

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

тому в app.config, який ви завантажуєте в WCFStorm, який ви хочете для ListsService:

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

2

Мені потрібні були такі прив'язки, щоб я почав працювати:

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.