从 IIS 进程(WCF 和 WF)通过 HTTPS 发布问题

发布于 2024-09-24 10:17:37 字数 692 浏览 1 评论 0原文

我有一些包装 PayflowPro .NET API 的代码。它本质上是从 C# 发送到 HTTPS 地址(支付网关)。我可以在本地运行此代码并且运行良好。我可以在我的 MSUnit 测试中运行它并且它可以工作,并且我可以从我的测试环境中的控制台应用程序运行它并且它也可以工作。

我有一个托管在 IIS 6.1 中的工作流,它实例化一个类,该类又调用此代码。当此工作流程启动时,代码每次都会失败;我收到类似 System.Exception: 无法从 API 对象连接到主机输入服务器 Uri = https://pilot-payflowpro.paypal.com/ 的错误。

这个异常来自 API,但我完全不知道如何从控制台应用程序而不是从 IIS 进程成功发布。

  • 课堂上的内容一模一样,一字不差。
  • 我以管理员身份登录,因此控制台应用程序以管理员身份运行。因此,我尝试使用网站应用程序池的管理员帐户(显然,仅用于此测试)
  • 控制台应用程序可以发布,因此防火墙/代理不会干扰......对吧?

我需要在 IIS 中调整什么才能允许应用程序与外部通信吗?是否有我忽略的明显安全设置?对于运行测试用例以找出可能发生的情况有什么建议吗?

编辑:事实证明,这个问题与服务器运行的虚拟机环境有关。这个问题不会发生在我的开发盒、测试服务器或生产服务器上 - 它只发生在集成服务器上。原因仍然未知,但我不再研究它。

I have some code that wraps the PayflowPro .NET API. It essentially posts to a HTTPS address (a payment gateway) from C#. I can run this code locally and it works nicely. I can run it in my MSUnit tests and it works, and I can run it from a console application on my test environment and it also works.

I have a workflow hosted in IIS 6.1, which instantiates a class which in turn calls this code. When this workflow is started the code fails everytime; I get an error like System.Exception: Failed to connect to host Input Server Uri = https://pilot-payflowpro.paypal.com/ from the API object.

This exception is coming from the API, but I am completely lost as to how I can succesfully post from a console application but not from an IIS process.

  • The class is exactly the same, word for word.
  • I log in as administrator, so the console app is running as administrator. Therefore I have tried using the administrator account for the application pool for the website (for this testing only, obviously)
  • The console app can post so therefore the firewall / proxy aren't interfering... right?

Is there anything I need to adjust in IIS to allow an application to communicate outside? Are there any obvious security settings that I'm overlooking? Any suggestions for test cases to run to find out what might be going on?

edit: Turns out that this problem is somehow related to the VM environment in which the server is running. This problem doesn't occur on my development box, the test server or the production server - it's only occurring on the integration server. The cause is still unknown but I am no longer working on it.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

你在看孤独的风景 2024-10-01 10:17:37

这可能是由 ASP.NET 信任配置问题引起的。要检查信任级别,请在编辑器中打开以下文件:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config(如果是 ASP.NET 2.0)

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\CONFIG\web.config(如果 ASP.NET 4.0)

您可能还需要编辑 C:\WINDOWS\Microsoft.NET\如果您在 64 位 Windows 上运行,则需要这些的 Framework64 版本。

向下滚动到 配置部分,如下所示:

<location allowOverride="false">
    <system.web>
        <securityPolicy>
            <trustLevel name="Full" policyFile="internal"/>
            <trustLevel name="High" policyFile="web_hightrust.config"/>
            <trustLevel name="Medium" policyFile="web_mediumtrust.config"/>
            <trustLevel name="Low" policyFile="web_lowtrust.config"/>
            <trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>
        </securityPolicy>
        <trust level="Medium" originUrl=""/>
    </system.web>
</location>

如果您看到 以外的任何内容,则显示表示服务器在部分信任下运行。

打开由相关 policyFile 属性指定的 .config 文件,例如 web_mediumtrust.config 如果 level="Medium" >。

服务器极不可能在低于低信任度的情况下运行。

找到 部分,在此下方有一个 ,如下所示:

<PermissionSet
    class="NamedPermissionSet"
    version="1"
    Name="ASP.Net">

这包含许多 节点。查找名为 WebPermission 的设置,它看起来像这样:

<IPermission
    class="WebPermission"
    version="1">

如果它丢失或看起来像这样:

<IPermission
    class="WebPermission"
    version="1">
    <ConnectAccess>
        <URI uri="$OriginHost$"/>
    </ConnectAccess>
 </IPermission>

您需要添加或修改,使其看起来像这样:

<IPermission 
    class="WebPermission" 
    version="1" 
    Unrestricted="true"/>

此设置控制从您的应用程序到或从您的应用程序的出站和入站访问一个 URI。

可能还需要确保 SocketPermission 配置的配置类似:

<IPermission 
    class="SocketPermission" 
    version="1" 
    Unrestricted="true"/>

This might be caused by an ASP.NET trust configuration issue. To check the trust level open the following file in an editor:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config (if ASP.NET 2.0)

C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\CONFIG\web.config (if ASP.NET 4.0)

You may also need to edit the C:\WINDOWS\Microsoft.NET\Framework64 versions of these if you're running on 64 bit Windows.

Scroll down to the <securityPolicy> configuration section which looks like:

<location allowOverride="false">
    <system.web>
        <securityPolicy>
            <trustLevel name="Full" policyFile="internal"/>
            <trustLevel name="High" policyFile="web_hightrust.config"/>
            <trustLevel name="Medium" policyFile="web_mediumtrust.config"/>
            <trustLevel name="Low" policyFile="web_lowtrust.config"/>
            <trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>
        </securityPolicy>
        <trust level="Medium" originUrl=""/>
    </system.web>
</location>

If you see anything other than <trust level="Full" originUrl=""/> it means the server is running under Partial Trust.

Open the .config file specified by the relevant policyFile attribute, for example web_mediumtrust.config if level="Medium".

It's highly unlikely that the server will be running under anything less than Low Trust.

Locate the <NamedPermissionSets> section, under this there is a <PermissionSet> that looks like:

<PermissionSet
    class="NamedPermissionSet"
    version="1"
    Name="ASP.Net">

This contains a number of <IPermission> nodes. Look for one that called WebPermission, it looks like this:

<IPermission
    class="WebPermission"
    version="1">

If it's missing or looks like:

<IPermission
    class="WebPermission"
    version="1">
    <ConnectAccess>
        <URI uri="$OriginHost$"/>
    </ConnectAccess>
 </IPermission>

You need to add or modify so it looks like:

<IPermission 
    class="WebPermission" 
    version="1" 
    Unrestricted="true"/>

This setting controls outbound and inbound access from your application to or from a URI.

It may also be necessary to ensure that the SocketPermission configuration is similarly configured:

<IPermission 
    class="SocketPermission" 
    version="1" 
    Unrestricted="true"/>
别低头,皇冠会掉 2024-10-01 10:17:37

事实证明,这个问题与服务器运行的虚拟机环境有关。这个问题不会发生在我的开发盒、测试服务器或生产服务器上 - 它只发生在集成服务器上。原因仍然未知,但我不再研究它。

Turns out that this problem is somehow related to the VM environment in which the server is running. This problem doesn't occur on my development box, the test server or the production server - it's only occurring on the integration server. The cause is still unknown but I am no longer working on it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文