Posted By: m1keread | Jun 10th, 2007 @ 1:48 PM
page 1 of 1
Comments: 7 | Views: 6980
m1keread
m1keread
Bored of Captions

I have a rather unusual request.

I have a webservice on a server written in C# and in it, I need to obtain the IP address of the Server that is calling it.

Using

HttpContext.Current.Request.UserHostAddress

I can get the IP address of my computer that is calling the web service.  But I will be calling my web service from various web sites and I only want it to be run from websites hosted in my server.  So I need the IP address of the server hosting the website, not the IP address of the computer making the request to the website.

Basically, my web service is sending emails and I only want it to be callable from sites that I control.  (Sites will be HTML, not necessarily ASP.NET.  I have sorted out plumbing between HTML and ASP.NET Web service already).

I have also tried

HttpContext.Current.Request.ServerVariables["REMOTE_ADDR"]

But I get the same result (The IP address of my computer, not the server hosting the website that is making the call to the web service).

Hope this makes sense.

I have also tried another way around the problem, but restricting access to the webservice by IP in IIS 6.  But once I had done a "Deny All", then "Grant IP of my Server".  The service could not be called from my server.  So if anyone knows any "oddities" with web services and Directory Security in IIS, I would be gratefull.


Many thanks for any thoughts

Mike


W3bbo
W3bbo
The Master of Baiters
A computer can have more than one IP address, which one are you after?

You could try and see if there's a class under System.Net that ASP.NET uses to represent the connection between the server and client, that would contain the address of both endpoints.
RichardRudek
RichardRudek
So what do you expect for nothin'... :P
I'm confused.

So are you saying that your user's Web Browser uses your Web Service, directly (AJAX/whatever), but you actually want the IP Address of the site that their Browser navigated to. In other words, you want you prevent others from (repackaging and) using your Web Service, yes ?


The only feasible way to do that is to route it through the server. A HTML/JS only script will just talk directly to your webservice from the client; Obviosuly you can't know whether that file is on your server, or the clients harddrive, or another server.

In other words, you'll want to set up a proxy postback or similar, that calls out to the service on the server side. That alone won't help anything against spamming however.
m1keread wrote:

prencher wrote:The only feasible way to do that is to route it through the server. A HTML/JS only script will just talk directly to your webservice from the client; Obviosuly you can't know whether that file is on your server, or the clients harddrive, or another server.



Thanks,

That seems to be exactly what is happening.  Maybe I should try a different tac. 

What I am after is a "Form to Email" solution for generic HTML sites (Not ASP.NET).  I thought my web service was an elegent solution, but if I cant nail it down, then I will have to try something like Frontpage extensions or I expect there are scripts out there somewhere

regards

Mike


It depends on your needs, but it might be enough to just limit the addresses you can send to through the script, and put a per-ip timeout on sending new e-mails.

Further I'd add a unique ID in a hidden field, so if abuse does happen, you can easily tell where it originated from, and eliminate that ID.

Obviously, you could then extend on that, and add a timeout per-ID as well as per-IP to make it even more robust. Etc etc.
RichardRudek
RichardRudek
So what do you expect for nothin'... :P
m1keread wrote:
...

What I dont want is "billy the script kiddie" copying my HTML page and sending his own emails via my web service.

Therefore, I was hoping for a way to stop any invocation of the web service except those coming from SERVER01.

...


So, it is as I described, then - you need to secure your Web Service.

I'm not a Web Developer, so I'm not familar with what is currently around for this. But if I were to design something like this, then the first thing you need to do is take the non-trusted party out of loop. ie Not have the client (Web Browser) use the Service.

However, if for some reason you have to involve the (non-trusted) client, then I would have the Web Server pass a token (permission) to the client, which must in turn supply this token to the Web Service. The token would need to be volatile. How volatile, would be dependent upon your needs. For example, it could even be a one-to-one, per message token, and/or expire after some amount of time, etc.

So the flow would be something like:

The Web Server obtains a batch of tokens from the Web Service, which it dispenses to the Browser as a hidden field (or whatever), and the javascript running on the Browser, passes the token on to your Web Service as a parameter. Your Web Service then validates the token, responding accordingly...

page 1 of 1
Comments: 7 | Views: 6980
Microsoft Communities