Проблемы при публикации через HTTPS из процесса IIS (WCF и WF) - PullRequest
1 голос
/ 21 сентября 2010

У меня есть код, который упаковывает API PayflowPro .NET. По сути, он отправляет на HTTPS-адрес (платежный шлюз) из C #. Я могу запустить этот код локально, и он прекрасно работает. Я могу запустить его в своих тестах MSUnit, и он работает, и я могу запустить его из консольного приложения в моей тестовой среде, и он также работает.

У меня есть рабочий процесс, размещенный в IIS 6.1, который создает класс, который в свою очередь вызывает этот код. Когда этот рабочий процесс запущен, код каждый раз завершается сбоем; Я получаю сообщение об ошибке типа System.Exception: Failed to connect to host Input Server Uri = https://pilot-payflowpro.paypal.com/ от объекта API.

Это исключение исходит от API, но я совершенно заблудился относительно того, как можно успешно отправлять сообщения из консольного приложения, но не из процесса IIS.

  • Класс точно такой же, слово в слово.
  • Я вхожу в систему как администратор, поэтому консольное приложение работает как администратор. Поэтому я попытался использовать учетную запись администратора для пула приложений для веб-сайта (очевидно, только для этого тестирования)
  • Консольное приложение может публиковать сообщения, поэтому брандмауэр / прокси-сервер не вмешиваются ... верно?

Что-то мне нужно настроить в IIS, чтобы приложение могло взаимодействовать с внешним миром? Есть ли очевидные настройки безопасности, которые я пропускаю? Какие-нибудь предложения для тестовых случаев, чтобы выяснить, что может происходить?

edit: Оказывается, эта проблема каким-то образом связана со средой виртуальных машин, в которой работает сервер. Эта проблема не возникает на моем компьютере для разработки, на тестовом сервере или на производственном сервере - она ​​возникает только на сервере интеграции. Причина до сих пор неизвестна, но я больше не работаю над ней.

Ответы [ 2 ]

1 голос
/ 22 сентября 2010

Это может быть вызвано проблемой конфигурации доверия 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\Framework64 их версии, если вы работаете в 64-битной Windows.

Прокрутите вниз до раздела конфигурации <securityPolicy>, который выглядит следующим образом:

<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>

Если вы видите что-то кроме <trust level="Full" originUrl=""/>, это означает, что сервер работает с частичным доверием.

Откройте файл .config, указанный соответствующим атрибутом policyFile, например web_mediumtrust.config, если level="Medium".

Маловероятно, что сервер будет работать с чем-либо меньшим, чем Low Trust.

Найдите раздел <NamedPermissionSets>, под ним есть <PermissionSet>, который выглядит следующим образом:

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

Содержит несколько узлов <IPermission>.Найдите тот, который называется 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"/>
0 голосов
/ 18 декабря 2010

Оказывается, что эта проблема как-то связана со средой виртуальных машин, в которой работает сервер.Эта проблема не возникает на моем компьютере для разработки, на тестовом сервере или на производственном сервере - она ​​возникает только на сервере интеграции.Причина до сих пор неизвестна, но я больше не работаю над ней.

...