publicar - wcf web config example
WCF WebService/IIS Hosting & Configuration Issue Detrás de un cortafuegos (6)
Tengo un servicio web WCF simple. Está alojado en IIS en el sitio web predeterminado en nuestro dominio de producción. (dirección local: 10.10.20.100)
De forma predeterminada, este sitio web predeterminado se configuró para IP "Sin asignar" en el Puerto 80: sin embargo, noté que esto hizo que el Servicio WCF generara su WSDL usando el nombre DNS local del servidor. es decir, todos los URI en el wsdl eran
http://myserver.subdomain.domain.com/.../...
Esto no fue bueno ya que necesito exponer este servicio a sitios que no tienen conocimiento del DNS interno de los entornos de producción. Y este servidor en particular no tiene un nombre DNS externo. Solo una dirección IP externa ...
He tenido cierto éxito al cambiar la configuración en IIS de "Todos los no asignados" -> "10.10.20.100"
Esto hace que el Servicio genere su WSDL con los URI
http://10.10.20.100/.../...
Esto está bien para otras máquinas dentro del subdominio y en otros subdominios, pero es aquí donde me quedo atascado. La dirección IP externa del servidor (1.2.3.4) se asigna a través de una traducción NAT / PAT para que no esté configurada explícitamente en la configuración IP del servidor (es decir, no se muestra en la configuración IP)
Entonces, si cambio la dirección IP del sitio web predeterminado de IIS de "Todos los no asignados" -> "1.2.3.4" como hice para la dirección interna, entonces el servicio WCF simplemente vuelve con ...
solicitud incorrecta (Nombre de host no valido)
Y si dejo IIS configurado en la dirección IP interna e intento acceder al servicio a través de la dirección IP externa que obtengo
No protocol binding matches the given address
''http://1.2.3.4/TestService/Service.svc''. Protocol bindings are
configured at the Site level in IIS or WAS configuration
¿Hay alguna forma de hacer que IIS / WCF genere sus URI WSDL con una dirección IP externa que no está explícitamente configurada en el servidor?
Alguien me ayude por favor antes de abandonar los servicios de WCF por la ventana.
¿Debe ser una dirección IP y no un FQDN? Al intercambiar a un FQDN y configurarlo en los encabezados del host para el sitio, luego se vincula a él a través de
cscript //nologo %systemdrive%/inetpub/adminscripts/adsutil.vbs set W3SVC/1/ServerBindings ":80:hostname.example.com"
luego, reciclar el grupo de aplicaciones producirá ese nombre de host en el WSDL generado. Obtendrá beneficios con eso: puede configurar un DNS interno que resuelva ese FQDN para la IP interna, y un DNS externo que resuelva su IP de firewall, luego el mismo sistema funcionará sin ningún cambio.
Así es como cambia el encabezado en IIS7. También ponga mi web.config para algunos si ayuda.
http://www.sslshopper.com/article-ssl-host-headers-in-iis-7.html
<?xml version="1.0"?>
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0" />
<customErrors mode="Off"></customErrors>
</system.web>
<system.serviceModel>
<client/>
<services>
<service name="WcfService1.Service1"
behaviorConfiguration="MyServiceTypeBehaviors">
<host>
<baseAddresses>
<add baseAddress="https://pws.sjukra.is/"/>
</baseAddresses>
</host>
<endpoint address="https://pws.sjukra.is/Service1.svc"
listenUri="/"
binding="wsHttpBinding"
contract="WcfService1.IService1"
bindingConfiguration="myBasicHttpBindingConfig"/>
<endpoint contract="IMetadataExchange"
binding="mexHttpsBinding"
address="mex"/>
</service>
</services>
<bindings>
<wsHttpBinding>
<binding name="myBasicHttpBindingConfig">
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="Windows" />
<message clientCredentialType="UserName"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="MyServiceTypeBehaviors">
<serviceMetadata httpsGetEnabled="true"/>
<serviceDebug httpsHelpPageEnabled="true" includeExceptionDetailInFaults="true"/>
<serviceCredentials type="System.ServiceModel.Description.ServiceCredentials">
<userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="WcfService1.Service1,WcfService1"/>
<serviceCertificate findValue="pws.sjukra.is" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" />
<clientCertificate>
<authentication certificateValidationMode="ChainTrust" revocationMode="NoCheck"/>
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true"></serviceHostingEnvironment>
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
</configuration>
Aunque este es un hilo antiguo, realmente me ayudó a migrar un proyecto de VS Web Developer Express a MonoDevelop, que incluía un servicio WCF.
La aplicación web solicitó la interfaz de JavaScript definida por el servicio WCF utilizando la siguiente URL: http://127.0.0.1:8080/path-to-service/service.svc/js , que me dio el error: Ningún enlace de protocolo coincide con el dirección dada
Inspirado por este hilo, pude solucionar el problema porque funcionaba el acceso al servicio con localhost en lugar de 127.0.0.1. Con una solicitud para http://localhost:8080/path-to-service/service.svc/js obtuve la interfaz de JavaScript.
En realidad, mi aplicación no usaba una URL absoluta para incluir la interfaz de JavaScript; sin embargo, al iniciar la aplicación desde MonoDevelop por primera vez, accedería a la aplicación utilizando 127.0.0.1, por lo que falló la llamada para incluir JavaScript desde el servicio.
Todavía no es perfecto, ya que no he podido iniciar la aplicación desde MonoDevelop utilizando localhost en lugar de 127.0.0.1, ya que la configuración de XSP solo me permite especificar una dirección IP, pero al menos sé cómo evitarlo.
El problema es que después de hacer un cambio en el puerto o la dirección IP, debe reiniciar el grupo de aplicaciones que usa, porque todavía tiene la información anterior hasta que se vuelva a reciclar.
Es porque no tiene configurados los encabezados de su host. Este parece ser un problema extremadamente común, me encuentro con él todo el tiempo. No hay configuración para el uris que genera, busca la dirección correcta examinando el encabezado del host del sitio. Incluso si está en un directorio virtual, debe ir al principal, en su caso, al directorio predeterminado y agregar un encabezado de host.
Avísame si no sabes cómo hacer esto.
Podría ser capaz de prevenir la violencia Ninja ... si entiendo tu problema ... Puedes especificar manualmente la dirección completa que el servicio debería usar en el web.config en lugar de tener el ServiceHost resolverlo por ti. Debes establecer la dirección base de tu servicio:
<service behaviorConfiguration="Behaviour1" name="Api.Poll">
<endpoint address="soap" binding="basicHttpBinding" bindingConfiguration="soapBinding"
contract="Api.IPoll" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://www.mydomain.com/Api" />
<add baseAddress="http://10.10.20.30/Api" />
</baseAddresses>
</host>
</service>
Con este método, su servicio debe aceptar la dirección base especificada, más el nombre del servicio, con la dirección de punto final adicional si tiene una. Además, necesitaría usar un ServiceHostFactory personalizado para establecer la dirección base mediante programación. Vea abajo:
public class ServiceHostFactory : System.ServiceModel.Activation.ServiceHostFactory
{
protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
{
ServiceHost host;
host = new ServiceHost(serviceType, baseAddresses[0]);
return host;
}
Por último, una vez que haya compilado la clase ServiceHostFactory, debe conectarlo a su servicio editando el marcado en el archivo .svc:
<%@ ServiceHost Language="C#" Debug="true" Service="Api.Poll" Factory="Api.ServiceHostFactory" CodeBehind="Poll.svc.cs" %>