2009-06-04 15 views
11

En nuestro proyecto tenemos un servicio web de Java que se ejecuta en http y https. Queremos usar http internamente y https para la versión externa de nuestra aplicación web.llamando a un servicio web usando WCF sobre Http y Https

Hemos creado la clase de proxy en nuestra aplicación y hemos configurado el enlace para http en la web/app.config y todo funciona bien.

¿Qué cambios tendríamos que hacer al código y la configuración para admitir https para el mismo servicio en nuestra aplicación externa? Si es posible, ¡proporcione fragmentos de código para explicar!

Respuesta

0

Por favor, vea Configuring HTTP and HTTPS:

Using Windows Communication Foundation (WCF) over HTTP either requires the use of a host, such as Internet Information Services (IIS), or manual configuration of the HTTP settings through the HTTP Server API. This document describes manually configuring WCF when using HTTP and HTTPS.

y también ver WCF Bindings Needed For HTTPS:

I just finished writing my first production WCF application, which worked very well until I deployed it to our production environment. All of a sudden none of the WCF calls would work, and I would get a JavaScript "TestService is not defined" error. When I look inside the JS service reference (in debug mode), I got the following error:

Could not find a base address that matches scheme http for the endpoint with binding WebHttpBinding. Registered base address schemes are [https]

So apparently my WCF service registered itself as HTTPS (since it is over SSL), but my binding was only configured for HTTP. The solution is to define a custom binding inside your Web.Config file and set the security mode to "Transport". Then you just need to use the bindingConfiguration property inside your endpoint definition to point to your custom binding. The entire HTTPS-enabled system.serviceModel section is below:

0

entiendo que está utilizando WCF para construir el cliente, que se conecta a un servicio web remoto, a través de HTTPS.

Para ello, basta con modificar el archivo de configuración del lado del cliente para la aplicación de potencia en WCF, en sustitución de http://server.address con https://server.address, en configuration/system.serviceModel/client/endpoint/@address. de este modo:

<configuration> 
    <system.serviceModel> 
    ... 
    <client> 
     <!-- change only the address string --> 
     <endpoint address="https://server.name/Whatever" 
      everything.else.stays.the.same /> 

    </client> 
    </system.serviceModel> 
</configuration> 

(La ruta de acceso al archivo de configuración varía de acuerdo a las normas regulares de .NET: si se trata de una aplicación ASPNET, o un servicio, o etc.)

O puede establecer el dirección explícita en el código:

// instantiate new proxy to web service 
    var svc= new ServiceClient(); 
    var e = svc.Endpoint; 
    e.Address = new System.ServiceModel.EndpointAddress("https://server.address/JavaServiceUri"); 

Le recomiendo encarecidamente que configure la dirección y no la codifique. Eso no significa que deba almacenarse en app.config, pero debe ser modificable. El proxy, también.

+0

esto no funciona para mi situación, que resulta en un sistema. ArgumentException con el mensaje "El esquema de URI provisto 'https' no es válido, se espera 'http'." – RenniePet

2

Supongo que está utilizando basichttpbinding. Luego hay que hacer dos cosas:

  • cambiar la dirección https :)
  • establecer el modo de seguridad para el transporte de
+0

nice - enlazando con la misma pregunta :) – Rory

+0

@Rory, buen truco, la respuesta ha estado allí más de un año, eres el primero en notar :) –

+0

Tan obvio como tu respuesta es, simplemente me ahorró potencialmente horas. 'Asumo que estás usando basichttpbinding'. Mi SLL estaba trabajando para SOAP, pero no funciona para webHttpBinding -REST. Ahora que identifiqué el problema, puedo comenzar a reparar :) – Doomsknight

22

encontré una respuesta a excavar alrededor de MSDN.

En mi caso, yo estaba usando un enlace personalizado:

<customBinding> 
    <binding name="jsonpBinding"> 
     <jsonpMessageEncoding/> 
     <httpTransport manualAddressing="true"/> 
    </binding> 
</customBinding> 

que fue referenciado en el servicio

<services> 
    <service name="{YourInfoHere}"> 
     <endpoint address="" binding="customBinding" bindingConfiguration="jsonpBinding" behaviorConfiguration="{YourInfoHere}" contract="{YourInfoHere}"/> 
    </service> 
</services> 

Adición de una segunda unión que utiliza httpsTransport y luego un segundo servicio que utiliza esa vinculante hizo el truco. Salida final:

<services> 
     <service name="{YourInfoHere}"> 
      <endpoint address="" binding="customBinding" bindingConfiguration="jsonpBinding" behaviorConfiguration="{YourInfoHere}" contract="{YourInfoHere}"/> 
      <endpoint address="" binding="customBinding" bindingConfiguration="jsonpBindingHttps" behaviorConfiguration="{YourInfoHere}" contract="{YourInfoHere}"/> 
     </service> 
    </services> 
    <bindings> 
     <customBinding> 
      <binding name="jsonpBinding"> 
       <jsonpMessageEncoding/> 
       <httpTransport manualAddressing="true"/> 
      </binding> 
      <binding name="jsonpBindingHttps"> 
       <jsonpMessageEncoding/> 
       <httpsTransport manualAddressing="true" /> 
      </binding> 
     </customBinding> 
    </bindings> 

Puede no ser ideal, pero funciona. Estos fueron los únicos cambios que hice para que SSL funcione. Dado que todo está en el transporte vinculante &, el código sigue siendo el mismo.

pertinentes enlaces de MSDN:

  1. personalizado Encuadernación: http://msdn.microsoft.com/en-us/library/ms731377.aspx
  2. HttpTransport: http://msdn.microsoft.com/en-us/library/system.servicemodel.channels.httptransportbindingelement.aspx
  3. HttpsTransport: http://msdn.microsoft.com/en-us/library/system.servicemodel.channels.httpstransportbindingelement.aspx
+3

+1 -Exactamente lo que estaba buscando :) –

Cuestiones relacionadas