Ошибка безопасности Silverlight WCF + SSL - файл crossdomain.xml никогда не запрашивался

Question

(я вижу несколько вопросов, связанных с моей проблемой, но ни одно из решений не работает для меня, так как я сталкиваюсь с этой проблемой на производстве, а не во время локальной разработки, и я уже попробовал все предложенные исправления.)

У меня есть приложение Silverlight 4, которое использует службы WCF, размещенные в IIS. В производстве эти услуги доступны через HTTPS. Несмотря на наличие действительного файла crossdomain.xml , я по-прежнему получаю известную «ошибку безопасности» при доступе к службе:

Произошла ошибка при попытке сделать запрос к URI 'https://MYDOMAIN/MYSERVICE.svc'. Это может быть связано с попыткой получить доступ к услуге междоменным способом без надлежащего междоменного политика или политика, которая не подходит для сервисов SOAP. Вы может потребоваться связаться с владельцем сервиса, чтобы опубликовать междоменный домен файл политики и гарантирует, что заголовки HTTP, связанные с SOAP, будут послал. Эта ошибка также может быть вызвана использованием внутренних типов в Интернете прокси службы без использования атрибута InternalsVisibleToAttribute. Пожалуйста, смотрите внутреннее исключение для более подробной информации. ---> System.Security.SecurityException ---> System.Security.SecurityException: ошибка безопасности ...

Используя Fiddler, я вижу, что к crossdomain.xml или clientaccesspolicy.xml не делается никаких запросов. Существует запрос CONNECT на сервер, но это все.

Я читал, что эта ошибка, хотя и указывает на проблему с crossdomain.xml / clientaccesspolicy.xml, также может возникать, когда сервер выдает недействительный сертификат. Похоже, что это не так в моем сценарии.

Я уверен, что правильно настроено следующее:
1. crossdomain.xml действителен и размещен в корневом каталоге сайта
2. Сервисы работают (у нас есть другие клиенты, использующие различные технологии, в том числе Adobe Flex, использующий crossdomain.xml.)
3. Приложение Silverlight работает (оно отлично работает с локальными службами и службами на общем сервере разработки ***)
4. Приложение Silverlight даже не пытается запросить crossdomain.xml или clientaccesspolicy.xml (что подтверждено Fiddler)
5. Приложение Silverlight использует правильную конфигурацию для доступа к WCF через https. Ниже приведена конфигурация:

<configuration>  
    <system.serviceModel>  
        <bindings>  
            <basicHttpBinding>  
                <binding name="BasicHttpBinding_IMyServices" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">  
                    <security mode="Transport" />  
                </binding>  
                </basicHttpBinding>  
        </bindings>  
        <client>  
            <endpoint address="https://MYDOMAIN/MYSERVICE.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IMyServices" contract="Services.IMyServices" name="BasicHttpBinding_IMyServices" />  
        </client>  
    </system.serviceModel>  
</configuration>

Что еще может вызвать такую ​​проблему? Может быть потому, что веб-серверы сбалансированы по нагрузке? Или есть проблема с сертификатом, который я не заметил? Если бы вы могли, по крайней мере, указать мне правильное направление, это было бы очень ценно.

(*** Что-то, на что стоит обратить внимание: я столкнулся с аналогичной проблемой в нашей среде разработки. Приложение Silverlight не смогло получить доступ к службам WCF на общем сервере разработки, несмотря на наличие надлежащего файла crossdomain.xml и отсутствие использования HTTPS. Я обошел это, добавив сервер разработки в качестве надежного сайта в IE. Однако этот же обходной путь не работает для производства, и даже тогда он не будет приемлемым обходным путем. Но тот факт, что я должен был сделать это в разработке окружающая среда заставляет меня беспокоиться, что я что-то пропустил по пути ...)

Answer 1

Проблема заключалась в том, что мне не хватало clientaccesspolicy.xml. Наличие crossdomain.xml было недостаточно в этом случае. Я думаю это потому, что вызов WCF был не только кросс-браузерным, но и кросс-протоколом (приложение Silverlight обслуживалось через http, но сервисы обслуживались через https).

Кроме того, мой clientaccesspolicy.xml должен был явно разрешить доступ для http следующим образом:

<?xml version="1.0" encoding="utf-8"?>  
<access-policy>  
    <cross-domain-access>  
        <policy>  
            <allow-from http-request-headers="SOAPAction">  
                <!-- IMPORTANT! Include these lines -->
                <domain uri="http://*"/>  
                <domain uri="https://*"/>  
            </allow-from>  
            <grant-to>  
                <resource path="/" include-subpaths="true"/>  
            </grant-to>  
        </policy>  
    </cross-domain-access>  
</access-policy>

Теперь работает как шарм.

Пара вещей, которые сбили меня с пути:

• Мой браузер кэшировал clientaccesspolicy.xml и crossdomain.xml. Мне придется очищать кэш каждый раз, когда я меняю один из этих файлов, или он не распознает более новую версию, несмотря на то, что IIS настроен на предотвращение кэширования этого файла клиентом.
• Запросы к clientaccesspolicy.xml и crossdomain.xml не всегда отображались в Fiddler. Вместо этого я часто вижу запросы CONNECT. Я не понимаю причину этого, но я научился не полагаться на Фиддлера, чтобы подтвердить, что эти запросы выполняются. Возможно, у меня где-то есть мошенническая настройка (и нет, это не настройка «Расшифровать HTTPS-трафик», которую я уже отключил).

Answer 2

У меня та же ошибка, когда я пытаюсь позвонить на мой сайт по протоколу http, и моя служба работает по протоколу HTTPS, она не удалась. Эта ошибка произошла из-за того, что на моей МКС не было сертификата, поэтому, когда приложение попыталось загрузить клиентскую политику доступа, оно не удалось.

Загляните в любой инструмент отладки в вашем браузере и найдите файл clientacccesspolicy, а затем проверьте, загружается ли он.