WCF connection information

  • Thread starter Thread starter r norman
  • Start date Start date
R

r norman

I have a client/server WCF application that uses a per-session
connection. I would like to maintain an audit trail of all connection
attempts. A valid user is required to login, and that login operation
contract can require specifying the source machine name and ip
address. However I would like to determine at least the ip address of
connection attempts that fail to do a proper login.

Is there any way to discover the ip address of a WCF connection
without actually making the client declare it? Certainly the
ServiceHost manager must keep track of it but I can't seem to find it
anywhere.
 
r norman said:
I have a client/server WCF application that uses a per-session
connection. I would like to maintain an audit trail of all connection
attempts. A valid user is required to login, and that login operation
contract can require specifying the source machine name and ip
address. However I would like to determine at least the ip address of
connection attempts that fail to do a proper login.

Is there any way to discover the ip address of a WCF connection
without actually making the client declare it? Certainly the
ServiceHost manager must keep track of it but I can't seem to find it
anywhere.
Click to expand...

Should be in the channel (where you'd also find the callback)...

Try:

OperationContext.Current.Channel.RemoteAddress
 
Should be in the channel (where you'd also find the callback)...

Try:

OperationContext.Current.Channel.RemoteAddress
Click to expand...

Thank you. I am relieved to find out that the location was not
obvious!

Unfortunately, my application produces an EndpointAddress of

{http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous}
which is not very useful. Is this because the client application
accesses the host using a service reference? I have tried tracing
through all the values of both the Channel and the RemoteAddress
looking for something useful to no avail.

The host specifies its address as
"net.tcp://localhost:8001/DynaCountHost" which is how the Channel
identifies its own local address. The client replaces "localhost" in
that string with the proper IP address. However the service reference
in the client application was created from

""http://localhost:8731/Design_Time_Addresses/DynaCountService/DynaCountWCFServer/"

It is all very confusing. However, I do require valid clients to
logon identifying their IP address before they can do anything so I
can live without the information. But it must be somewhere!
 
OperationContext.Current.Channel.RemoteAddress
Thank you. I am relieved to find out that the location was not
obvious!

Unfortunately, my application produces an EndpointAddress of

{http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous}
which is not very useful. Is this because the client application
accesses the host using a service reference? I have tried tracing
through all the values of both the Channel and the RemoteAddress
looking for something useful to no avail.

The host specifies its address as
"net.tcp://localhost:8001/DynaCountHost" which is how the Channel
identifies its own local address. The client replaces "localhost" in
that string with the proper IP address. However the service reference
in the client application was created from

""http://localhost:8731/Design_Time_Addresses/DynaCountService/DynaCountWCFServer/"

It is all very confusing. However, I do require valid clients to
logon identifying their IP address before they can do anything so I
can live without the information. But it must be somewhere!
Click to expand...

Not sure I understand your problem, we're talking about identifying the
remote client 'from' the server, right?

Something like this works..


[ServiceContract(Namespace="something.local")]
interface IServer
{
[OperationContract]
void Test();
}

public class Server : IServer
{
public Server()
{
// On first call, OperationContext.Current.Channel.RemoteAddress can
be called here
}

public void Test()
{
// OperationContext.Current.Channel.RemoteAddress can be called here
}
}
 
Thank you. I am relieved to find out that the location was not
obvious!

Unfortunately, my application produces an EndpointAddress of

{http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous}
which is not very useful. Is this because the client application
accesses the host using a service reference? I have tried tracing
through all the values of both the Channel and the RemoteAddress
looking for something useful to no avail.

The host specifies its address as
"net.tcp://localhost:8001/DynaCountHost" which is how the Channel
identifies its own local address. The client replaces "localhost" in
that string with the proper IP address. However the service reference
in the client application was created from

""http://localhost:8731/Design_Time_Addresses/DynaCountService/DynaCountWCFServer/"

It is all very confusing. However, I do require valid clients to
logon identifying their IP address before they can do anything so I
can live without the information. But it must be somewhere!
Click to expand...

Not sure I understand your problem, we're talking about identifying the
remote client 'from' the server, right?

Something like this works..


[ServiceContract(Namespace="something.local")]
interface IServer
{
[OperationContract]
void Test();
}

public class Server : IServer
{
public Server()
{
// On first call, OperationContext.Current.Channel.RemoteAddress can
be called here
}

public void Test()
{
// OperationContext.Current.Channel.RemoteAddress can be called here
}
}
Click to expand...

Yes. Both I want to identify the client from the server.
And I do essentially what you say but get

{http://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous}
as the contents of RemoteAddress. Acctually it is
RemoteAddress.ToString()
and is the value of RemoteAddress.Uri.AbsoluteUri.

The other stuff was my just desperately trying to provide whatever
information I could think of to help -- so I talked about
irrelevancies on how the host announces its address and how the client
knows about the service and the address.
 
Back
Top