El servicio WCF falló en la autenticación en el servidor 2012, ¡pero está bien en Win7?

Question

Había creado un servicio WCF con autenticación de bases de rol y autorización. Y la implementación de cada operación es como

[PrincipalPermission(SecurityAction.Demand, Role = RoleConstants.Customer)]
[PrincipalPermission(SecurityAction.Demand, Role = RoleConstants.CustomerStaff)]
public void DoSomething()
{
}

El proveedor de miembros y Rolemanager son los de MySQL, no en GAC. Los certificados SSL son generados por IIS 7 para HTTPS.

y tengo algunas pruebas de integración como

using (var client = new MyProxy("DefaultBinding_ILicensingService"))
{
    client.ClientCredentials.UserName.UserName = "AbcShop";
    client.ClientCredentials.UserName.Password = "tttttttt";

    client.DoSomething();
}

Una instancia se está ejecutando en mi máquina DEV de Win7, y la otra está en un servidor de prueba del servidor 2012. Ambas instancias del servicio WCF habían estado funcionando bien.

Sin embargo, después de 1 mes, descubrí que la instancia en el servidor 2012 ya no funciona, y falló en la autenticación, con el siguiente mensaje.

Actualización:

System.ServiceModel.Security.MessageSecurityException : An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
---- System.ServiceModel.FaultException : An error occurred when verifying security for the message.
Stack Trace:

Server stack trace: 
   at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.ProcessReply(Message reply, SecurityProtocolCorrelationState correlationState, TimeSpan timeout)
   at System.ServiceModel.Channels.SecurityChannelFactory`1.SecurityRequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)

Actualización:

He observado lo siguiente y descartado algunas causas posibles.

1. Las bases de datos de autenticas en ambas máquinas son idénticas, y pude ver que el servicio WCF está haciendo que las consultas SQL para recuperar la información de los miembros después de que el cliente esté haciendo una solicitud.
2. Comparé la vinculación y los ajustes de IIS, así como web.config en ambas máquinas, que son básicamente idénticas, excepto algunas direcciones.
3. El espectador de eventos no muestra ninguna advertencia sobre el servicio WCF.
4. La implementación del servicio WCF está decorada por esto atribuido: Error de clase pública HandlerBehaviorAttribute: Atributo, IserviceBehavior, IerRorhandler, y todas las excepciones no detectadas irán a este atributo, sin embargo, iniciará los errores en un archivo de registro, sin embargo, el archivo de registro no registró nada para este asunto.

y yo había comparado los ensamblajes cargados en ambas instancias. En Windows 7, los ensamblajes del sistema son básicamente de Windows \ Microsoft.NET \ ensambling \ gacxxx \ xxx, sin embargo, en el servidor 2012, algunos asambleos son de Windows \ ensamblaje \ nativoimages_v4.0.30319_64, aquí están algunos ensamblajes ubicados en ivAmages:

System   
System.Activities   
System.Core   
System.Data.DataSetExtensions   
System.Drawing   
System.Enumerics
System.ServiceModel.Activities   
System.WorkflowServices   
System.XAML   
System.ServiceModel.Web

En contraste, en Win 7, solo el sistema es de ivAdimages. No estoy seguro de si la ubicación de las asambleas o las imágenes nativas podría alterar los comportamientos.

Los servicios y clientes se desarrollan utilizando VS 2012 en .NET Framework 4.5.

¿Qué más podría hacer que la instancia en el servidor 2012 falle?

Answer 1

problemas resueltos.

La raíz de las causas: faltan ensamblajes MVC ASP .NET en el servidor 2012.

El fondo es, quiero que el servicio WCF compartiera la misma base de datos de autenticación con las aplicaciones de MVC que se construirán en el futuro. Por lo tanto, el proveedor de miembros y el administrador de autos son los de MVC, y la base de datos es MYSQL, por lo que los proveedores son de un componente de terceros de código abierto que se acopla con MVC.

Las razones por las cuales mi controlador de excepciones sin captura y el espectador de eventos no pudieron atrapar las advertencias sobre los ensamblajes faltantes son: 1. El Dev PC fue utilizado por un desarrollador anterior que amaba a GAC. Sabes que GAC podría causar muchos problemas en una PC de DEV. Toneladas de montaje de MVC 1,2, y 3 estaban en GAC. 2. El tercer componente que interactúa con MVC tiene alguna práctica de programación deficiente en algún lugar en algún lugar de tragar algunas excepciones sobre los ensamblajes faltantes.

Después de comparar los conjuntos cargados uno por uno en ambas máquinas, encontré que la instancia de servicio WCF en el servidor 2012 no tenía WebMatrix.WebData.dll. Después de copiar el ensamblaje al directorio bin del directorio virtual, obtuve una cadena de mensajes de error sobre más ensamblajes faltantes después de que copié los ensamblajes faltantes reportados uno por uno. Estas asambleas básicamente pertenecen a MVC. Los mensajes de error aparecieron en el lado del cliente en la respuesta del servicio en HTML, así como al visor de eventos en el lado del servidor.

Así que ahora aseguro de que los scripts de implementación incluyan conjuntos respectivos.

Aparentemente después de la información del miembro recuperado del servicio de la base de datos de autenticación, el servicio delegará la información a otras asambleas de MVC para su procesamiento adicional, y de alguna manera el 3er componente tragó la excepción sobre los ensamblajes faltantes. Y las otras partes de la autenticación obtuvieron una señal incorrecta, y luego le dieron un mensaje de advertencia engañoso sobre "Verificación de la seguridad ...".

La lección es: 1. No gac en la máquina dev. Si heredó una máquina DEV de alguien, mejor invertir en algún momento de ONU-GAC, que debería haber sido asambleas privadas a través de Xcopy. 2. Algunos componentes de terceros podrían tener alguna práctica sucia contra la programación defensiva. En mi caso, el componente tragó las advertencias sobre los ensamblajes faltantes. 3. Es más barato comparar conjuntos cargados antes de investigar otras posibles causas. Utilizo el Explorador de procesos para listar ensamblajes cargados en w3wp.exe.