"The test form is only available for requests from the local machine."
You can work around this issue by modifying your web.config
to include these nodes:
<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>
This will allow you to visit the .asmx web service via your browser. You can then invoke the web services right in your browser, pass arguments, and view the results.
Just FYI I'm using .NET 4.0 and had this same problem.
However I used...
<add name="HttpSoap12"/>
<add name="HttpSoap"/>
<add name="HttpGet"/>
<add name="HttpPost"/>
In those same areas and it worked. But with just HttpGet
and HttpPost
it did not.
HTTP GET and HTTP POST Are Disabled by Default
If you are publishing metadata and it's a public/unsecured web service, you are right, it would be easy enough for anyone to generate a simple client to hammer away at your web service. In that case, having the web client only generated on the local machine does seem like a nuisance.
If your service is private and secured, however, it would be a huge security hole, giving anyone with the name of the server and service an authenticated client to use to potentially access your data and do all kinds of harm.
I imagine the policy of generating the UI for ASMX Web services only on the server itself was an attempt to provide some nice tooling while eliminating accidental security holes. WCF has done away with this in any case, you can generate clients only if the metadata is published, and they need to implement the correct security in order to access the services.