“测试表单仅适用于来自本地计算机的请求。”

Question

我在 .Net 中创建了一个 Web 服务，因此服务文件的地址有一个关于它如何工作的漂亮的自动生成的解释。当我从托管的计算机上运行该页面时，它甚至有一个可用于向服务提交测试值的表单。然而，在远程计算机上，它会隐藏表单并给出如上所示的消息。

这有道理吗？我见过其他网站称此为“更安全”，但任何人都可以轻松创建自己的表单，如果你问我的话，这只不过是一个麻烦。

Answer 1

您可以通过修改

web.config

以包含这些节点来解决此问题：

<configuration>
    <system.web>
     <webServices>
        <protocols>
            <add name="HttpGet"/>
            <add name="HttpPost"/>
        </protocols>
    </webServices>
    </system.web>
</configuration>

这将允许您通过浏览器访问 .asmx Web 服务。然后，您可以直接在浏览器中调用 Web 服务、传递参数并查看结果。

Answer 2

仅供参考，我正在使用 .NET 4.0 并遇到了同样的问题。

但是我用过...

<add name="HttpSoap12"/>
<add name="HttpSoap"/>
<add name="HttpGet"/>
<add name="HttpPost"/>

在那些相同的领域，它奏效了。但只有

HttpGet

和

HttpPost

却没有。

Answer 3

HTTP GET 和 HTTP POST 默认禁用

Answer 4

如果您要发布元数据并且它是公共/不安全的 Web 服务，那么您是对的，任何人都可以很容易地生成一个简单的客户端来攻击您的 Web 服务。在这种情况下，仅在本地计算机上生成 Web 客户端似乎确实很麻烦。

但是，如果您的服务是私有且安全的，这将是一个巨大的安全漏洞，为任何知道服务器和服务名称的人提供经过身份验证的客户端，用于潜在地访问您的数据并造成各种危害。

我认为仅在服务器本身上为 ASMX Web 服务生成 UI 的策略是尝试提供一些不错的工具，同时消除意外的安全漏洞。无论如何，WCF 已经废除了这一点，只有在发布元数据的情况下才可以生成客户端，并且它们需要实现正确的安全性才能访问服务。

Answer 5

我遇到了同样的问题，将其添加到 web.config

</system.web>
<webServices>
  <protocols>
    <add name="HttpSoap12"/>
    <add name="HttpSoap"/>
    <add name="HttpGet"/>
    <add name="HttpPost"/>       
  </protocols>
</webServices>