Silverlight WCF + SSL security error-crossdomain.xml никогда не запрашивал

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

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

An error occurred while trying to make a request to URI 'https://MYDOMAIN/MYSERVICE.svc'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details. ---> System.Security.SecurityException ---> System.Security.SecurityException: Security error...

Используя Fiddler, я вижу, что никакой запрос на crossdomain не делается.xml или clientaccesspolicy.XML. Есть запрос на подключение к серверу, но это все.

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

Я уверен, что следующее настроено правильно:
1. кроссдомен.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 службы на общем сервере разработки, несмотря на наличие соответствующего кросс-домена.xml и не использовать HTTPS. Я обошел его, добавив сервер разработки в качестве надежного сайта в IE. Однако этот же обходной путь не работает для производства, и даже тогда это не было бы приемлемым обходным путем. Но тот факт, что я должен был сделать это в среде разработки, заставляет меня беспокоиться, что я что-то упустил на этом пути...)

2 7
https wcf crossdomain.xml silverlight-4.0

2 ответа:

Проблема заключалась в том, что мне не хватало clientaccesspolicy.XML. Имея кроссдомен.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 и кроссдомен.XML. Мне пришлось бы очищать свой кэш каждый раз, когда я изменял один из этих файлов, или он не распознал бы более новую версию, несмотря на то, что IIS настроен для предотвращения кэширования этого файла клиентом.
* Запросы к clientaccesspolicy.xml и кроссдомен.xml не всегда появлялись в Fiddler. Вместо этого я часто видел запросы на подключение. Я не понимаю причины этого, но ... Я научился не полагаться на скрипача, чтобы подтвердить, что эти запросы выполняются. Возможно, у меня где-то есть какая-то мошенническая настройка (и нет, это не настройка "расшифровать HTTPS-трафик", которую я уже отключил).

10

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

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

3