2011-09-20 8 views
5

Tengo un servicio WCF que tiene múltiples métodos web en él. Quiero poder interceptar la solicitud en todos los métodos y mirar la dirección Ip. Id preferiría no poner la lógica en una llamada a método en la parte superior de cada método web llamado ¿hay alguna manera de interceptar todas las llamadas a estos métodos desde un solo lugar?¿Cómo puedo interceptar todas las llamadas a métodos en un servicio WCF .svc?

Si fuera una página, escribiría un objeto de página base pero no estoy seguro de si hay eventos planteados en una llamada wcf?

+0

Puede usar los inspectores en el WCF [Inspectors] (https://web.archive.org/web/20120207232924/http://cgeers.com:80/2008/11/09/wcf-extensibility-parameter -inspectors /) – dhinesh

+0

El enlace de comentarios de arriba de @dhinesh parecía cargar una página con malware y quería que instalara una extensión de Chrome. Lo he informado al moderador. – Volomike

+0

Me gustaría sugerir que elimine la etiqueta asp.net porque su pregunta es mucho más amplia que asp.net y puede ser muy útil para codificadores C# y codificadores VB con .NET. – Volomike

Respuesta

3

WCF le permite implementar interceptores que se agregan a la pila. Vea esto link para un ejemplo. No estoy seguro de si esto le permite extraer la IP de los remitentes, pero creo que vale la pena intentarlo.

3

Puede implementar IDispatchMessageInspector y hacer algo como esto.

public object AfterReceiveRequest(ref Message request, 
IClientChannel channel, InstanceContext instanceContext) 
    { 
     RemoteEndpointMessageProperty remoteEndpoint = request.Properties 
    [RemoteEndpointMessageProperty.Name] as RemoteEndpointMessageProperty; 

     //remoteEndpoint.Address will give you the address. 

     return null; 
    } 
+0

¿Hay alguna manera fácil de adjuntar esto al servicio WCF antes de la llamada 'host.Open()'? Lo único que vi fue que tuve que crear un comportamiento especial, un enlace y luego un inspector de mensajes. Me arranqué el pelo tratando de resolver esto y finalmente me rendí. Luego descubrí 'ServiceAuthorizationManager'. – Volomike

1

Hay una forma inteligente de hacer esto con la ServiceAuthorizationManager, y es mucho más fácil que todo el duro trabajo serio de la IDispatchMessageInspector.

Crear una clase en su proyecto de servicio WCF, así:

public class MyServiceAuthorizationManager : ServiceAuthorizationManager 
{ 
    protected override bool CheckAccessCore(OperationContext operationContext) 
    { 
    string classMethod = operationContext.RequestContext.RequestMessage.Headers.Action; 
    if (classMethod.Contains("/transfer/Get")) 
    { 
     return true; // because someone is simply updating a client service reference 
    } 
    Console.WriteLine("Class Method Call: {0}",classMethod); 
    // do something with operationContext here as you need to inspect stuff 
    // return true if you want this class method call to succeed and go through 
    // return false if you want this class method to fail on the client 
    return true; 
    } 
} 

Luego, en su servicio, justo antes de su llamada host.Open(), introduce el enlace a MyServiceAuthorizationManager.

ServiceHost host = new ServiceHost(typeof(MyProject.Service1)); 
host.Authorization.ServiceAuthorizationManager = new MyServiceAuthorizationManager(); 
host.Open(); 

Ahora cuando se prueba las conexiones del cliente, se dará cuenta de que las salidas de la consola qué método de clase fue llamado. También puede trabajar contra todas las cosas en el objeto operationContext.

Una forma en que uso esto es para una comprobación de encabezado de seguridad. En mi cliente, agrego un encabezado. Luego, en el servicio, en esta llamada CheckAccessCore(), verifico que este encabezado personalizado existe. Si no lo hace, entonces devuelvo falso. Esta es una capa más de protección que mantiene alejados a los piratas informáticos, y también es excelente para la seguridad limitada en las configuraciones de Canalizaciones con nombre. Si también quiere hacer eso, entonces click here para obtener más información sobre cómo agregar encabezados personalizados que se envían automáticamente en el método de cada cliente para llamar al servicio.

Y tenga en cuenta, entre todo esto, que no tuve que meterme con comportamientos, reclamos, oyentes o mensajes enviados. Tampoco necesité editar mi Configuración WCF.

Tenga en cuenta la verificación de cadena para /transfer/Get anterior. Esto es importante si está haciendo comprobaciones de encabezado como un mecanismo de seguridad como yo. Si no tiene esa condición y devuelve verdadero, su IDE de cliente WCF no puede actualizar su ServiceReference porque el IDE no sabe sobre ese encabezado adicional (si está agregando un encabezado personalizado y no especifica ese encabezado en el Aplicación del cliente WCF.config). De lo contrario, obtendrá un error The URI prefix is not recognized.

Cuestiones relacionadas