WCF за общедоступным обратным прокси-сервером, который используется для шифрования трафика.

У меня есть приложение Silverlight, которое подключается к службе WCF. В базовой конфигурации, к которой я привык, нет проблем с подключением этого приложения к соответствующей службе WCF.

Однако недавно один из моих клиентов начал использовать обратный прокси-сервер Apache. Этот прокси является общедоступным сервером и используется только для шифрования HTTP-трафика через SSL (HTTPS), идущего между клиентом и им. Этот прокси передает весь трафик с него на фактический веб-сервер, на котором размещено мое приложение. Трафик между общедоступным прокси-сервером и сервером IIS представляет собой обычный HTTP.

Итак, поток трафика выглядит следующим образом: Браузер конечного пользователя --- HTTPS----> Общедоступный обратный прокси-сервер -----HTTP----> Сервер IIS, на котором размещена служба WCF.

Обратный прокси-сервер и IIS находятся на двух отдельных серверах.

Я не могу заставить приложение Silverlight работать должным образом. Я не уверен, как настроить конечные точки? У меня возникают проблемы всякий раз, когда я использую адрес общедоступного прокси-сервера в качестве адреса конечной точки.

Приложение Silverlight обычно имеет следующую конфигурацию:

<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IPOTemplateEditorSrv" maxBufferSize="2147483647"
                    maxReceivedMessageSize="2147483647">
                    <security mode="TransportWithMessageCredential" />
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="https://public-reverse-proxy-url/POTemplateEditorSrv.svc"
                binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IPOTemplateEditorSrv"
                contract="POEditorSrvRef.IPOTemplateEditorSrv" name="BasicHttpBinding_IPOTemplateEditorSrv" />
        </client>
    </system.serviceModel>
</configuration>

Обратите внимание, что я использую, и у меня есть адрес конечной точки, указывающий на общедоступный HTTPS-адрес обратного прокси-сервера.

Я что-то упустил? Возможно, есть какая-то дополнительная информация для настройки прокси? Любые обходные пути, которые позволили бы моему клиенту Silverlight подключиться к службе?


asp.net wcf wcf-binding wcf-security silverlight
person Zaki Saadeh    schedule 28.08.2012    source источник
comment
Можно ли получить доступ к службе напрямую, когда вы вводите URL-адрес (public-reverse-proxy-url/POTemplateEditorSrv. svc) в браузере?   -  person boris    schedule 31.08.2012
comment
Да, я могу. Я на самом деле попробовал это, и у меня не было проблем с просмотром страницы, созданной WCF, когда вы обращаетесь к этой странице. Когда я это делаю, я получаю страницу, которая говорит мне, что вы создали службу. Чтобы протестировать эту службу, вам нужно будет создать клиент и использовать его для вызова службы. Вы можете сделать это с помощью svcutil.exe... (я усекаю остальную часть сообщения, которое получаю)   -  person Zaki Saadeh    schedule 31.08.2012
comment
Какие проблемы возникают при попытке подключения из Silverlight? Следующим моим шагом было бы запустить инструменты разработчика в IE9 (F12) или Fiddler и посмотреть на запрос, который генерирует клиент Silverlight (если есть), и ответ, который он получает (если есть).   -  person boris    schedule 31.08.2012
comment
Дело в том, что когда приложение Silverlight загружается с сервера браузером, а затем загружается и запускается, оно не запрашивает ресурсы svc, как должно, и как это происходит с любым моим приложением, у которого нет общедоступный прокси для этого.   -  person Zaki Saadeh    schedule 01.09.2012
comment
Видите ли вы какие-либо исключения в Silverlight? Правильно ли настроены и загружены с сервера файлы clientaccesspolicy/crossdomain?   -  person boris    schedule 01.09.2012
comment
Спасибо Борис. Я только что воспользовался консолью ошибок IE и обнаружил, что получаю: Необработанная ошибка в приложении Silverlight. Удаленный сервер вернул ошибку: NotFound. в System.Runtime.CompilerServices.AsyncVoidMethodBuilder.‹SetException›b__0(состояние объекта).... Я также просмотрел WSDL, связанный с требуемой службой, и обнаружил, что ‹wsdl:service› ‹soap:address location= адрес частного сервера›. Есть также другие импорты для локальных схем xsd, ссылающихся на частный адрес. Вы знаете, почему он привязывает эти ресурсы к локальному частному серверу, а не к публичному?   -  person Zaki Saadeh    schedule 01.09.2012
comment
Тот факт, что вы говорите, что приложение вообще не запрашивает ресурсы svc, и тот факт, что вы получаете удаленный сервер, возвращает ошибку ... исключение не складывается. Запрос либо отправляется и получает ответ от удаленного сервера, либо нет. Удаленно диагностировать такие вещи сложно, но я могу сказать вам, что мы используем очень похожую конфигурацию (с балансировщиком нагрузки/ускорителем SSL), и она работает просто отлично. Единственная разница, которую я вижу, заключается в том, что мы используем только режим безопасности транспорта.   -  person boris    schedule 04.09.2012

Ответы (1)


arrow_upward
4
arrow_downward

Возможно, этот ответ слишком очевиден, но это просто звучит так, как будто WSDL объявляет внутреннее имя хоста как адрес WCF, когда этот адрес не является фактически общедоступным. Поскольку IIS генерирует WSDL, он просто использует имя своего хоста в адресах конечных точек, а это не то, что вам нужно, вам нужен адрес прокси.

Попробуйте создать статическую копию файла WSDL и опубликовать ее на своем веб-сервере. Убедитесь, что вы заменили ВСЕ ССЫЛКИ на внутреннее имя хоста на имя хоста общедоступного прокси. Затем измените конфигурацию клиента WCF, чтобы она указывала на статический WSDL. Здесь вы можете найти краткое объяснение: ">Укажите другой адрес конечной точки в WSDL веб-службы WCF

Если это не сработает — попробуйте использовать сниффер (wireshark) для захвата того, что отправляется туда и обратно — отключение HTTPS может быть частью, которую вам нужно удалить из уравнения. Похоже, что ваш запрос веб-службы ОТПРАВЛЕН на прокси-сервер, но прокси-сервер не может правильно обработать запрос — идеальный сценарий, чтобы попробовать наши инструменты анализа.

Когда вы делаете прямой запрос к SVC с помощью веб-браузера, запрос будет выглядеть примерно так:

GET /POTemplateEditorSrv.svc HTTP/1.1
Host: public-reverse-proxy-url

Но при отправке через Silverlight это может выглядеть так

GET /POTemplateEditorSrv.svc HTTP/1.1
Host: private-server-address

Это может быть достаточно тонкой разницей, чтобы расстроить прокси.

person Adam    schedule 04.09.2012
comment
+1 Отличный ответ. В частности (согласно прилагаемой ссылке), измените значение <soap:address> в файле <wsdl:service><wsdl:port>. Вам не нужно размещать файл на веб-сервере; вы можете просто «открыть» его со своего рабочего стола. - person Kirk Broadhurst; 05.09.2012
comment
Хорошо, спасибо, Адам. Я попробую это и вернусь к вам через день или два! - person Zaki Saadeh; 06.09.2012
comment
Я еще не пробовал это на клиентском сервере, но это решение имеет для меня смысл, и я его приму. - person Zaki Saadeh; 07.09.2012