Спонсор: Microsoft
Опубликован: 01.03.2010 | Доступ: свободный | Студентов: 942 / 39 | Оценка: 4.38 / 4.31 | Длительность: 09:26:00
Лекция 3:

Работа вне браузера и с web-сервисами

< Лекция 2 || Лекция 3: 123456 || Лекция 4 >

Особенности при работе с веб-сервисами

Не всегда производительность веб-сервисов устраивает разработчика приложения Silverlight. При взаимодействии приложения Silverlight и веб-сервиса происходит обмен XML сообщениями. Такой формат вызывает излишний трафик. Поэтому в Silverlight 3 предусмотрен двоичный формат данных Binary XML и он является форматом по умолчанию ( <binaryMessageEncoding /> -строка файла web.config). Binary XML характеризуется компактностью и возможностью индексации содержимого. Использование двоичного формата позволяет сократить размеры пересылаемых сообщений, увеличить скорость их обработки. Формат Binary XML направлен на увеличение производительности, но не является способом сжатия. Хотя этот эффект также присутствует.

Повышение производительности при использовании Binary XML

Рис. 3.23. Повышение производительности при использовании Binary XML

Тестирование приложения (см. результаты теста на рис. 3.23) показывает, что при высокой нагрузке двоичный формат имеет значительное преимущество в количестве обрабатываемых запросов. При 20 передаваемых объектах прирост составил 24%, а при 100 объектах уже 71%.

Уменьшение размеров сообщений при использовании формата Binary XML

Рис. 3.24. Уменьшение размеров сообщений при использовании формата Binary XML

Кроме того, происходило уменьшение размеров сообщений (см. рис. 3.24). "Коэффициент сжатия" для строковых переменных составил 15%.

Другим важным моментом является обработка исключений. Например, при возникновении необрабатываемого исключения на стороне сервиса на стороне клиента возникает ошибка соединения CommunicationException, которая сама по себе мало о чем говорит. Если в WCF включить флаг IncludeExceptionDetailsInFaults (по умолчанию false, сделать true: <serviceDebug includeExceptionDetailInFaults="true"/> ), то даже в этом случае подробности исключения не доступны на клиенте Silverlight. Это происходит потому, что приложение Silverlight является плагином для браузера. И если сервис выдает исключение, то он посылает браузеру HTTP сообщение с кодом 500, а не 200. В этом случае приложение Silverlight не получает от браузера никаких сообщений. Решение здесь таково, что в любом случае надо посылать HTTP сообщение с кодом 200. Пример "Message Inspector Sample" в Silverlight 2 доступен по адресу http://code.msdn.com/SilverlightWS. В Silverlight 3 это можно сделать проще, т.к. имеется поддержка классов Faults: System.ServiceModel.ExceptionDetail и FaultException<T>.

Безопасность приложений Silverlight основывается на безопасности ASP.NET. Пользователь заходит на страницу *.aspx с контейнером для приложения Silverlight и аутентифицируется на ней. Полученное разрешение используется приложением Silverlight. Схема работает нормально, если используется один домен (рис. 3.25). Если злоумышленники хотят подменить приложение и выводят пользователя на другой домен и оттуда пользователь получает доступ к информации, тогда возможно нарушение безопасности (рис. 3.26). Ситуация, когда приложение из одного интернет домена работает с веб-сервисом из другого домена, называется кроcсдоменный доступ.

Регистрация пользователя

Рис. 3.25. Регистрация пользователя

Регулирование кроcсдоменного доступа в технологии Silverlight происходит с помощью файла clientaccesspolicy.xml либо файла crossdomain.xml, используемого технологией Flash. Файл размещается в корне сайта, например, mydomain.com/clientaccesspolicy.xml. По умолчанию кросдоменный доступ запрещен.

Кроcсдоменный доступ

Рис. 3.26. Кроcсдоменный доступ

Вот URL такого файла http://video.msn.com/clientaccesspolicy.xml, и его содержимое:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from>
        <domain uri="*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Это означает, что доступ разрешен из любого домена. И другой файл http://video.msn.com/crossdomain.xml:

<?xml version="1.0"?>
<cross-domain-policy>
  <allow-access-from domain="*.msn.com" /> 
  <allow-access-from domain="sand.msn-int.com" />
  <allow-access-from domain="articles.moneycentral.alpha.msn-int.com" />
  <allow-http-request-headers-from domain="*.msn.com" 
                   headers="SOAPAction"/>
</cross-domain-policy>

Тут видно, что для flash-приложений разрешен доступ только с определенных доменов.

Браузерная аутентификация, т.е. аутентификация, основанная на файлах cookie, или windows аутентификация, подходит только в том случае, если веб-сервис находится в одном домене, что и приложение Silverlight, либо доступ ограничен только доверенными доменами. В остальных случаях нужно использовать Message-based аутентификацию.

При Message-based аутентификации передача логина и пароля осуществляется в URL или в SOAP-заголовках.

Message-based аутентификация

Рис. 3.27. Message-based аутентификация

Аутентификация осуществляется непосредственно из приложения Silverlight (рис. 3.27). В таком случае вредное приложение не может получить доступ к специфичной информации, имеющейся в распоряжении легального приложения. Передавать логин и пароль можно как параметр:

[OperationContract]
public decimal GetInfo(int accountID, string userName, string password);

Можно использовать расширения WCF, что требует глубоких знаний WCF. Но можно использовать возможности Silverlight 3. Надо указать в файле ServiceReferences.ClientConfig приложения Silverlight:

<bindings>
  <customBinding>
    <binding name="CustomBinding_Service1">
      <binaryMessageEncoding />
      <security authenticationMode="UserNameOverTransport"/>                    
      …
    </binding>
  </customBinding>
</bindings>

И в файле Web.config сайта:

<bindings>
  <customBinding>
    <binding name="customBinding0">
      <security authenticationMode="UserNameOverTransport"/>
      <binaryMessageEncoding />
      <httpTransport />
    </binding>
  </customBinding>
</bindings>

Кроме того, в этом же файле надо указать:

<behaviors>
  <serviceBehaviors>
    <behavior name="SilverlightApplication1.Web.Service1Behavior">
      <serviceCredentials>
        <userNameAuthentication userNamePasswordValidationMode="Custom"/>
      </serviceCredentials>
      …
    </behavior>
  </serviceBehaviors>
</behaviors>

В этом случае в коде C# можно использовать прокси-класс следующим образом:

ServiceReference1.Service1Client client = new ServiceReference1.Service1Client();
client.ClientCredentials.UserName.UserName = "test";
client.ClientCredentials.UserName.Password = "test";

Следует помнить, что в заголовках SOAP имя и пароль будут передаваться в открытом виде, а значит, приложение должно использовать протокол HTTPS. В Silverlight 3 имеется утилита SlSvcUtil.exe, расположенная в каталоге C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Tools. Она позволяет более гибко настраивать безопасность приложения Silverlight.

< Лекция 2 || Лекция 3: 123456 || Лекция 4 >