Silverlight сервисный крест WCF доменный вопрос
Оптимизатор не сделал очень хорошего задания. Обычно они могут быть преобразованы без любого различия, и оптимизатор может сделать это.
2 ответа
Да, вам понадобится файл clientaccesspolicy.xml в ROOT домена вашей службы (webservices.mydomain.net).
По умолчанию Silverlight поддерживает вызовы веб-служб на том же домен или сайт происхождения. Один и тот же домен означает, что вызовы должны использовать один и тот же поддомен, протокол и порт. Это сделано из соображений безопасности и предотвращает междоменную подделку.
Вот пример файла:
<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="http://intranet.mydomain.net"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Это разрешит запросы только из intranet.mydomain.net.
Изменить
Был задан вопрос: Как это будет работать, если у меня две службы WCF? /ServiceA/a.svc и /ServiceB/b.svc, и я хочу, чтобы ServiceA была открыта для всех и в любом месте, а ServiceB работала только из моей интрасети?
Ваш файл политики будет выглядеть следующим образом:
<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="http://*"/>
</allow-from>
<grant-to>
<resource path="/ServiceA/" include-subpaths="true"/>
</grant-to>
</policy>
<policy>
<allow-from http-request-headers="*">
<domain uri="http://intranet.mydomain.net"/>
</allow-from>
<grant-to>
<resource path="/ServiceB/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Возможно, вы захотите проверить следующую ссылку о «Как использовать файлы междоменной политики с Silverlight » Tim Heuer .
http://silverlight.net/learn/videos/all/how-to-use-cross-domain-policy-files-with-silverlight/
Вот еще одна страница из блога Тима Хойера, которую вы можете прочитать, также примеры:
Я бы подумал о написании вашего собственного WCF сервис, который живет с вашим приложением Silverlight и обрабатывает запрос к вашей внешней службе WCF. Таким образом, вы ничего не оставляете открытым, и разрешается только связь с вашей контролируемой службой (хотя служба, которую вы упомянули, может находиться под вашим контролем).
Этот метод также полезен, когда другая служба находится вне ваших рук и может часто меняться. Вы можете контролировать, как это будет обрабатываться через свой собственный сервис, и вам никогда не придется обновлять элемент управления silverlight (при условии, что изменения не являются радикальными).