I’m working on a web service using C# and targeting the .NET 2.0 Framework. Nothing terribly fancy, but it has some code to log the caller’s IP address (via HttpContext.Current.Request.UserHostAddress). While testing the code, I like using the test form functionality that .NET provides with web services. By design, it only works locally. If you try to use the test form from a remote machine, you’ll get the error:
The test form is only available for requests from the local machine
That’s fine, when you expose a web service you don’t want to make it too easy for people to start poking at your web service methods with a pointy stick. Still, I wanted to test it from another machine and it saves time being able to enter in different values without having to code up a test framework. Plus, I wanted to make sure that my code was reliably picking up the caller’s IP address.
After just a tiny bit of searching in the series of tubes, I found how to easily enable the web service test form for remote connections. Juan Ignacio Gelos posted what you need to add to the web service web.config file to enable the test form.
<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>
You are still limited to run methods that have simple data types as input, but it’s very handy for testing. Since this setting lives in web.config, it’s easy to remove it when I run a build. I’m using FinalBuilder on a dedicated build box and it’s easy to clean up .config files so that developer settings get scrubbed before the files get packages into an installer.
Have you experienced the test form returning the machine name rather than the domain name as the test form's action attribute?
ReplyDelete