consume - WCF sobre SSL-Error 404

wcf service c# https (10)

Acabo de pasar unas horas en esto y resultó que mi problema era el nombre del servicio

<services> <service name="TimberMill.Web.Data.LogReceiverService"> <endpoint binding="basicHttpBinding" bindingConfiguration="basicBinding" contract="NLog.LogReceiverService.ILogReceiverServer" /> </service> </services>

tenía que coincidir exactamente con la entrada similar en mi archivo * .svc.

<%@ ServiceHost Language="C#" Debug="true" Service="TimberMill.Web.Data.LogReceiverService, TimberMill.Web" Factory="Autofac.Integration.Wcf.AutofacServiceHostFactory, Autofac.Integration.Wcf" CodeBehind="LogReceiverService.svc.cs" %>

No estoy seguro si estaba relacionado con mi uso de Autofac. Todo funcionaba bien en HTTP simple. Falló bajo HTTPS sin embargo.

Bueno, creo que sí, no quiero molestar nada ahora probando con más detalle para no enojar a los dioses WCF-Config y mi configuración se rompe de nuevo. YMMV.

De acuerdo, me falta algo completamente simple aquí, porque he estado buscando en Google durante días y mirando docenas de respuestas allí, y aquí en SO, y simplemente NO PUEDO hacer que esto funcione, sin importar lo que haya intentado. El servicio funciona perfectamente bien cuando se llama a través de HTTP simple.

Aquí está nuestra configuración ... tenemos un dominio, http://www.mydomain.com . Tenemos un certificado SSL instalado en ese dominio de thawte, tal como lo haríamos si estuviéramos asegurando un sitio de comercio electrónico. Todo funciona bien, y puedo ir a http s : //www.mydomain.com y funciona bien. Estoy ejecutando el sitio VS2008, .NET 3.5 en Windows Server 2003 R2.

Ahora, agregué un servicio WCF habilitado para Silverlight a mi sitio, con el que quiero comunicarme a través de SSL. Si busco http s : //www.mydomain.com/myservice.svc, me muestra la página descriptiva WSDL " Usted ha creado un servicio " como se esperaba, que muestra cómo crear su cliente usando

svcutil.exe https:// ...

EDITAR: Me di cuenta de que la url mostrada para el svcutil en el archivo wsdl en realidad apuntaba al nombre físico del servidor web, no al dominio apropiado. Así que seguí los pasos que se muestran en esta publicación del blog para actualizar SecureBinding del sitio web en IIS mediante el script adsutil. Ahora el archivo wsdl muestra la dirección SSL correcta, pero sigo recibiendo el mismo error.

Ahora fui y traté de conectar mi aplicación Silverlight, y no funciona, devolviendo una excepción en el resultado de las llamadas asincrónicas, indicando " El servidor remoto devolvió un error: NotFound . Varios de los blogs que tengo Leí hablar sobre limitarlo a los problemas de Silverlight al crear una aplicación de Windows de prueba y tratar de hacer referencia a eso. Bueno, lo hice e incluso en una aplicación de Windows regular que intenta acceder al servicio a través de SSL recibo una excepción que dice:

System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at https://www.mydomain.com/mysubdir/myservice.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. ---> System.Net.WebException: The remote server returned an error: (404) Not Found. at System.Net.HttpWebRequest.GetResponse() at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)

Esto a pesar del hecho de que agregué explícitamente la referencia de servicio a la aplicación de Windows usando el esquema HTTPS y obtiene todos los métodos de manera adecuada y los muestra en Intellisense en el editor.

Tenga en cuenta que este es un servicio que NO requiere un inicio de sesión explícito por parte del usuario. Voy a enviar encabezados personalizados en mis sobres SOAP para verificar que las solicitudes provengan de nuestra aplicación, y solo quiero evitar que los depredadores detecten la línea y seleccionen los encabezados personalizados.

Ahora, al código, donde simplemente debo tener un pequeño ajuste estúpido equivocado, porque por lo que he leído, este debería ser un ejercicio bastante directo.

Primero, la clase de código subyacente de mi servicio está decorada con los siguientes atributos:

<ServiceBehavior(AddressFilterMode:=AddressFilterMode.Any)> <AspNetCompatibilityRequirements(RequirementsMode:=AspNetCompatibilityRequirementsMode.Allowed)>

La sección de ServiceModel de mi web.config en el servidor se ve así:

<system.serviceModel> <bindings> <basicHttpBinding> <binding name="basicHttpBinding"> <security mode="Transport"> <transport clientCredentialType ="None"/> </security> </binding> </basicHttpBinding> </bindings> <behaviors> <serviceBehaviors> <behavior name="standingsBehavior"> <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/> <serviceDebug includeExceptionDetailInFaults="false"/> </behavior> </serviceBehaviors> </behaviors> <serviceHostingEnvironment aspNetCompatibilityEnabled="true"> <baseAddressPrefixFilters> <add prefix="http://www.mydomain.com:80"/> </baseAddressPrefixFilters> </serviceHostingEnvironment> <services> <service behaviorConfiguration="standingsBehavior" name="lijslwebdata"> <endpoint address="" binding="basicHttpBinding" contract="lijslwebdata"/>  </service> </services> </system.serviceModel>

Y la sección ServiceModel de la aplicación.config en mi aplicación de Windows tiene el siguiente aspecto:

<system.serviceModel> <bindings> <basicHttpBinding> <binding name="BasicHttpBinding_lijslwebdata" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" maxBufferSize="65536" maxBufferPoolSize="524288" maxReceivedMessageSize="65536" messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true"> <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" /> <security mode="Transport"> <transport clientCredentialType="None" proxyCredentialType="None" realm=""/> <message clientCredentialType="UserName" algorithmSuite="Default" /> </security> </binding> </basicHttpBinding> </bindings> <client> <endpoint address="https://www.mydomain.com/mysubdir/myservice.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_lijslwebdata" contract="xdata.lijslwebdata" name="BasicHttpBinding_lijslwebdata" /> </client> </system.serviceModel>

Antes no funcionaba para usted porque llamó a su configuración básica de HTTPttling "basicHttpBinding" pero no hizo referencia a esa configuración en su etiqueta con bindingConfiguration = "basicHttpBinding"

En los cambios que funcionó agregando otra configuración de servicio, usted hizo referencia a la configuración de enlace que contiene el nodo y, por lo tanto, lo hace funcionar.

De acuerdo, aparentemente solucioné el problema, y no tengo ni idea de por qué o cómo.

Esto es lo que hice.

Agregué un NUEVO SERVICIO WCF EMPTY Silverlight habilitado
Luego actualicé el web.config para reflejar ambos servicios
Luego, literalmente, copié y pegué todo sobre el primer servicio en el segundo servicio, excepto el nombre.

Por qué esto lo solucionó, no tengo absolutamente ninguna idea.

FWIW para cualquiera, aquí está mi nueva sección de Web.config ServiceModel con el segundo servicio en ella ...

<system.serviceModel> <bindings> <basicHttpBinding> <binding name="basicHttpBinding"> </binding> <binding name="basicHttpsBinding"> <security mode="Transport"> <transport clientCredentialType ="None"/> </security> </binding> </basicHttpBinding> </bindings> <behaviors> <serviceBehaviors> <behavior name="standingsBehavior"> <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/> <serviceDebug includeExceptionDetailInFaults="false"/> </behavior> </serviceBehaviors> </behaviors> <serviceHostingEnvironment aspNetCompatibilityEnabled="true"> <baseAddressPrefixFilters> <add prefix="http://www.mydomain.com/"/> </baseAddressPrefixFilters> </serviceHostingEnvironment> <services> <service behaviorConfiguration="standingsBehavior" name="lijslwebdata"> <endpoint address="" binding="basicHttpBinding" contract="lijslwebdata"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> </service> <service behaviorConfiguration="standingsBehavior" name="sslwebdata"> <endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttpsBinding" contract="sslwebdata"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> </service> </services> </system.serviceModel>

En mi caso, ninguna de estas respuestas me ayudó.

En cambio, necesité agregar una sección <binding> duplicada que no tiene un atributo de name establecido .

Aquí está el volcado de la sección apropiada del archivo web.config de mi servicio:

Espero que esto pueda ser útil para alguien, algún día.

Estuve lidiando con esto recientemente, y quiero agregar una modificación. Si sigue las instrucciones anteriores, podrá hacer que el servicio funcione con HTTPS, pero no simultáneamente en HTTP y HTTPS. Para hacer eso, necesita tener dos nodos de configuración de punto final, uno para cada protocolo de la siguiente manera:

<service name="MyCompany.MyService" > <endpoint address="" behaviorConfiguration="AspNetAjaxBehavior" binding="webHttpBinding" contract="MyCompany.MyService" bindingConfiguration="sslBinding" /> <endpoint address="" behaviorConfiguration="AspNetAjaxBehavior" binding="webHttpBinding" contract="MyCompany.MyService" /> </service>

(tomado de mi base de código, ajuste el comportamientoConfiguración y enlace según corresponda)

Otra cosa más para comprobar si se encuentra con el mismo error 404 que OP. Jugué un montón de cosas, pero finalmente la solución se redujo a simplemente agregar el espacio de nombres a mi servicio web.config.

Tan simple viejo ServiceFoo e IServiceFoo NO funcionó:

<services> <service behaviorConfiguration="quuxBehavior" name="ServiceFoo"> <endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttpsBinding" contract="IServiceFoo"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> </service> </services>

Pero al agregar el espacio de nombres (ProjectBar) DID funciona:

<services> <service behaviorConfiguration="quuxBehavior" name="ProjectBar.ServiceFoo"> <endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttpsBinding" contract="ProjectBar.IServiceFoo"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> </service> </services>

Todo parece ser bastante válido, sin errores evidentes en absoluto ...

Solo una observación / pregunta: ¿dónde está ubicado su archivo * .svc?

En el mensaje de error, veo:

https://www.mydomain.com/myservice.svc

¿Su archivo * .svc está realmente en el directorio virtual de nivel superior de su sitio?

Normalmente, el archivo * .svc está dentro de un directorio virtual en IIS y, por lo tanto, la dirección sería algo así como:

https://www.mydomain.com/YourVirtualDirectory/myservice.svc

Por supuesto, puede implementar una aplicación ASP.NET y un archivo * .svc del servicio WCF en la raíz de su IIS, pero no es muy común, en mi experiencia.

Solo una cosita para comprobar .....

Bagazo

Tuve el mismo problema y pasé un día para resolver este problema. Finalmente debajo de la configuración me funcionó para el acceso HTTPS.

Tuve este mismo problema en mi extremo. Tu publicación me ayudó a descubrir cuál era el problema. aquí está mi sección de modelo de servicio. Descubrí que las claves eran httpsGetEnabled y luego establecía la configuración de enlace . Espero que esto ayude.

<system.serviceModel> <behaviors> <serviceBehaviors> <behavior name="RequestImageBehavior"> <serviceMetadata **httpsGetEnabled**="true" /> <serviceDebug includeExceptionDetailInFaults="false" /> <dataContractSerializer maxItemsInObjectGraph="1073741824" /> </behavior> </serviceBehaviors> </behaviors> <services> <service behaviorConfiguration="RequestImageBehavior" name="RequestImage"> <endpoint address="" binding="wsHttpBinding" **bindingConfiguration**="HttpsBinding" contract="IRequestImage"> </endpoint> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> </services> <bindings> **<wsHttpBinding> <binding name="HttpsBinding"> <security mode="Transport"> <transport clientCredentialType="None"/> </security> </binding> </wsHttpBinding>** </bindings> </system.serviceModel>

Varias de las respuestas me llevaron a reconfigurar mi web.config para contener dos puntos finales. Terminé con este siguiente Web.config.

<system.serviceModel> <bindings> <basicHttpBinding> <binding name="basicHttpBinding"> </binding> <binding name="basicHttpsBinding"> <security mode="Transport"> <transport clientCredentialType ="None"/> </security> </binding> </basicHttpBinding> </bindings> <behaviors> <serviceBehaviors> <behavior name="standingsBehavior"> <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/> <serviceDebug includeExceptionDetailInFaults="false"/> </behavior> </serviceBehaviors> </behaviors> <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true"> <baseAddressPrefixFilters> <add prefix="http://www.myhost.com"/> </baseAddressPrefixFilters> </serviceHostingEnvironment> <services> <service behaviorConfiguration="standingsBehavior" name="NameSpace.ClassName"> <endpoint address="" binding="basicHttpBinding" contract="NameSpace.ContractInterfaceName"/> <endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttpsBinding" contract="NameSpace.ContractInterfaceName"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> </service> </services> </system.serviceModel>