I need a way to uniquely identify the machine, IP Address or user that called a web service. We are attempting to loosely integrate
two applications where both apps, running on a single machine, will call a web service to communicate a few simple tokens. The
problem is that there can be multiple users on different PC's using the system and I need to save the source of the token so that it
is picked up by the correct machine.

One of the apps is an Oracle Financials app that has very limited ability for customization and the other will be a VB2005 app that
can have unlimited customization. The oracle app will pass a Document ID via the Web Service. The VB app will call another web
method to see what document it needs to display. I need a way to uniquely identify that both apps are running on the same machine.

I hope this makes sense.

"Al Reid" <areidjr> wrote in message
news:6124
> I need a way to uniquely identify the machine, IP Address or user that
> called a web service. We are attempting to loosely integrate
> two applications where both apps, running on a single machine, will call a
> web service to communicate a few simple tokens. The
> problem is that there can be multiple users on different PC's using the
> system and I need to save the source of the token so that it
> is picked up by the correct machine.
>
> One of the apps is an Oracle Financials app that has very limited ability
> for customization and the other will be a VB2005 app that
> can have unlimited customization. The oracle app will pass a Document ID
> via the Web Service. The VB app will call another web
> method to see what document it needs to display. I need a way to uniquely
> identify that both apps are running on the same machine.

Are you using Windows Authentication for the server? If so, then
HttpContext.Current.User will contain accurate information on the
authenticated user.

The machine is a tougher thing. You can get the UserHostName property (see
http://msdn.microsoft.com/en-us/libr...rhostname.aspx),
but that relies on DNS, and therefore won't always work. Same with
UserHostAddress, which relies on IP address, and is therefore even worse
(what about multiple network interfaces, proxy servers, or who knows what?)

Now, I've never used them, but maybe client certificates would help. If IE
can be configured to respond with a certificate automatically, then that
takes care of the Oracle Financials application. If you can do it in IE,
then you can certainly do it in you VB application. Give each machine its
own certificate, and you then have uniqueness.

"John Saunders" <no> wrote in message news:6044
> "Al Reid" <areidjr> wrote in message
> news:6124
>
> Are you using Windows Authentication for the server? If so, then
> HttpContext.Current.User will contain accurate information on the
> authenticated user.
>

The users are on another network on the other side of a T1 and we are not part of their domain.

> The machine is a tougher thing. You can get the UserHostName property (see
> [..]),
> but that relies on DNS, and therefore won't always work. Same with
> UserHostAddress, which relies on IP address, and is therefore even worse
> (what about multiple network interfaces, proxy servers, or who knows what?)
>

I have found that
Me.Context.Request.UserHostAddress



works within our local network. I sent a link to our partner on the other side of the T1 line to test if the correct IP
address arrives after passing through the routers and firewalls.


> Now, I've never used them, but maybe client certificates would help. If IE
> can be configured to respond with a certificate automatically, then that
> takes care of the Oracle Financials application. If you can do it in IE,
> then you can certainly do it in you VB application. Give each machine its
> own certificate, and you then have uniqueness.
>

I've never worked with client certificates either, but the idea seems feasible.

Thanks, John.

"Al Reid" <areidjr> wrote in message
news:a276
> "John Saunders" <no> wrote in message
> news:6044
>
> The users are on another network on the other side of a T1 and we are not
> part of their domain.
>> I have found that
> Me.Context.Request.UserHostAddress
>>
> works within our local network. I sent a link to our partner on the
> other side of the T1 line to test if the correct IP
> address arrives after passing through the routers and firewalls.

Of course, it may work today, yet, over the weekend their network
administrators may install some new piece of hardware that changes the
picture. That's why software should not depend on something 'way down at the
Network layer of the protocol stack - it's not meant for you.