Март 2011

// Выводит:

trace(novel. processingInstructions( )[0].toStringC ));

Определение равенства в расширении Е4Х

В этом разделе рассматриваются специальные правила языка ActionScript для определения равенства объектов XML, XMLList, QName и Namespace. Стоит отметить, однако, что представленная информация применима только к оператору равенства (==) — она не касается оператора строгого равенства (===). Расширение Е4Х не изменяет семантику оператора строгого равенства. В частности, этот оператор считает два экземпляра класса XML, XMLList — QName или Namespace — равными тогда, и только тогда, когда они указывают на одну и ту же объектную ссылку.

Равенство объектов XML

Оператор равенства (==) считает два экземпляра класса XML, представляющие элементы, равными, если они представляют одну и ту же иерархию XML. Например, в следующем коде переменные xl и х2 указывают на различные объектные ссылки, но считаются равными, поскольку представляют одну и ту же иерархию XML:

var xl:XML = ; var x2:XML = ; trace(xl == x2); // Выводит: true

По умолчанию расширение E4X игнорирует пробельные узлы, поэтому два экземпляра класса XML, представляющие элементы, считаются равными, когда имеют одинаковую разметку, даже если используется различное форматирование. Например, в следующем коде исходный XML-код для экземпляра класса XML, хранящегося в переменной xl, не содержит пробельные узлы, в отличие от исходного XML-кода для экземпляра класса XML, хранящегося в переменной х2, который содержит два пробельных узла. Однако, несмотря на это различие, экземпляры по-прежнему

считаются равными, поскольку пробельные символы игнорируются — это значит, что иерархии XML остаются одинаковыми.

var xl:XML = ; var x2:XML =

;

trace(xl == x2): // По-прежнему выводит: true

Если перед парсингом кода XML мы скажем среде Flash учитывать пробельные узлы, экземпляры класса XML из предыдущего примера больше не будут считаться равными, как показано в следующем коде:

XML. ignoreWhitespace = false: // Не игнорировать пробельные узлы var xl:XML = : var x2:XML =

:

trace(xl == x2); // Теперь выводит: false

Экземпляр класса XML, представляющий элемент, считается равным экземпляру класса XML, представляющему атрибут, если элемент не имеет элементов-детей и содержащийся в нем текст совпадает со значением атрибута. Например, в следующем коде атрибут QUANTITY считается равным элементу, поскольку элемент не имеет элементов-детей и содержит текст, который совпадает со значением атрибута QUANTITY:

var product:XML = 1: trace(product.^QUANTITY == product. COST); // Выводит: true

Подобным образом экземпляр класса XML, представляющий элемент, считается равным экземпляру класса XML, представляющему текстовый узел, если элемент не имеет элементов-детей и содержащийся в нем текст совпадает со значением текстового узла. Например, в следующем коде текстовый узел, содержащийся в элементе, считается равным элементу, поскольку второй элемент не имеет элементов-детей и содержит текст, который совпадает со значением текстового узла-ребенка первого элемента:

var product:XML =

1 1 :

trace(product. COST.*[0] == product. QUANTITY): // Выводит: true

Во всех остальных случаях, если типы узлов двух экземпляров класса XML отличаются, эти два экземпляра считаются разными. Когда типы узлов совпадают, два экземпляра считаются равными, если типом обоих узлов является:

? «атрибут», а значения атрибутов совпадают;

? «текст», а текст узлов совпадает;

? «комментарий», а текст, расположенный между открывающими и закрывающими разделителями комментария (), совпадает;

? «инструкция обработки», а текст, расположенный между открывающими и закрывающими разделителями инструкции обработки (), совпадает.

Равенство объектов XMLList

Чтобы определить, являются ли два экземпляра класса XMLList равными, среда выполнения Flash сравнивает по порядку все экземпляры в этих объектах, используя правила определения равенства объектов XML, которые были рассмотрены в предыдущем разделе. Если хотя бы один элемент из первого экземпляра класса XMLList не равен соответствующему элементу из второго экземпляра, два экземпляра класса XMLList считаются неравными. Например, в следующем коде объект XMLList, возвращаемый выражением msgl. *, считается равным объекту XMLList, возвращаемому выражением msg2 . *, поскольку каждый экземпляр класса XML из результата выражения msgl. * считается равным экземпляру класса XML в соответствующей позиции из результата выражения msg2 . *:

var msgl:XML = World J. Programmer Hello :

var msg2:XML = World J. Programmer Hello ;

trace(msgl.* == msg2.*): // Выводит: true

Экземпляр класса XML и объект XMLList, содержащий один-единственный экземпляр класса XML, сравниваются точно так же, как два экземпляра класса XML:

traceCmsgl. FROM == msg2.*[l]); // Выводит: true

Это значит, что оператор равенства (==) считает объект XMLList с одним-един-ственным экземпляром класса XML равным этому экземпляру!

traceCmsgl. FROM == msgl. FROM[0]): // Выводит: true

Чтобы отличить объект XMLList, содержащий один-единственный экземпляр класса XML, от этого экземпляра, используйте оператор строгого равенства (===):

traceCmsgl. FROM === msgl. FROM[0]): // Выводит: false

Равенство объектов QName

Класс QName представляет имя элемента или атрибута, уточняемое пространством имен. Два экземпляра класса QName считаются равными, если их названия пространств имен и локальные имена совпадают (то есть они имеют одинаковые значения переменных uri и localName). Например, следующий код создает объект QName с помощью конструктора класса QName и сравнивает этот объект с объектом QName, полученным из XML-документа. Оба объекта QName имеют одинаковые названия пространств имен и локальные имена, поэтому считаются равными.

var product:XML = xmlns:someCorp=»http://www. example. com/someCorp»>

99.99 :

var someCorp:Namespace = product. namespace(«someCorp»);

var qnl:QName = new QNameC’http://www. example. com/someCorp», «PRICE»):

var qn2:QName = product. someCorp:.PRICE. name( ):

trace(qnl == qn2): // Выводит: true

Равенство объектов Namespace

Класс Namespace представляет уточняющую часть имени, которое уточняется с помощью пространства имен. Два объекта Namespace считаются равными тогда, и только тогда, когда они содержат одно и то же название пространства имен (то есть когда их переменные uri хранят одно и то же значение), независимо от префикса. Например, следующий код создает объект Namespace с помощью конструктора класса Namespace и сравнивает созданный объект с объектом Namespace, полученным из XML-документа. Оба объекта Namespace содержат один и тот же идентификатор URI, поэтому считаются равными, несмотря на то, что префиксы отличаются.

Var product:XML = xmlns:someCorp=»http://www. example. com/someCorp»>

99.99 : var nsl:Namespace = product. namespace(«someCorp»):

var ns2:Namespace = new NamespaceC’sc», «http://www. example. com/someCorp»): trace(nsl == ns2): // Выводит: true

Дальнейшее изучение

В этой главе была рассмотрена большая часть основной функциональности расширения Е4Х, однако исчерпывающее описание выходит за рамки данной книги. Для дальнейшего изучения посмотрите на описание методов и переменных классов XML и XMLList в справочнике по языку ActionScript корпорации Adobe. Все технические детали можно найти в спецификации расширения Е4Х по адресу http://www. ecma-intemational^rg/publications/standards/Ecma-357.htm

Далее по программе — знакомство с ограничениями безопасности приложения Flash Player. Если изучение этой темы не кажется вам приятным занятием, можете перейти сразу к части II, где будут рассматриваться вопросы отображения содержимого на экране. Просто помните, что если в процессе разработки вы столкнетесь с ошибками безопасности, глава 19 поможет вам решить появившиеся проблемы.

ГЛАВА 19

Ограничения безопасности

Flash Player

Чтобы предотвратить передачу данных несанкционированным получателям без соответствующего разрешения, приложение Flash Player тщательно проверяет все запросы на загрузку или на доступ к внешним ресурсам либо на взаимодействие с другими SWF — или HTML-файлами. Любой запрос к внешнему ресурсу из SWF-файла (к ресурсу, который не является частью скомпилированного SWF-файла, осуществляющего запрос), отвергается или принимается на основании таких факторов, как:

? операция языка ActionScript, используемая для доступа к ресурсу;

? статус безопасности SWF-файла, выполняющего запрос;

? местоположение ресурса;

? набор явных прав доступа для ресурса, которые определены либо создателем ресурса, либо его распространителем;

? явные права доступа, предоставленные пользователем (например, разрешение на подключение к камере или микрофону пользователя);

? тип приложения Flash Player, выполняющего SWF-файл (например, версия встраиваемого расширения, автономная версия, отладочная версия среды разработки Flash).

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

Распространитель ресурса — сторона, которая занимается распространением данного ресурса. Обычно это оператор сервера, например администратор сайта или сокетного сервера.

Создатель ресурса — сторона, которая фактически является автором ресурса. Для SWF-файлов создателем ресурса является разработчик на языке ActionScript, который скомпилировал данный SWF-файл.

Пользователь — пользователь компьютера, на котором выполняется приложение Flash Player.

В этой главе сначала рассматриваются ограничения безопасности приложения Flash Player в общих чертах, после чего описывается конкретное влияние безопасности на загрузку содержимого и на обращение к внешним данным.

В этой главе мы рассмотрим ограничения безопасности одной конкретной среды Flash: приложения Flash Player (версии, реализованной в виде модуля расширения браузера, и автономной версии). Информацию об ограничениях безопасности, налагаемых другими средами выполнения Flash (например, приложениями Adobe AIR и Flash Lite), можно найти в документации корпорации Adobe.

Чего нет в этой главе

Перед тем как перейти к изучению материала, проясним один момент: безопасность — это очень обширная тема. Всестороннее рассмотрение безопасности приложения Flash Player выходит за рамки этой книги. Более того, в этой главе рассматриваются функции безопасности, предназначенные лишь для защиты пользователей Flash-содержимого, но не обсуждаются вопросы разработки защищенных приложений, например сайтов для электронной коммерции. Гораздо более полную информацию о безопасности, включая вопросы разработки защищенных приложений, например использование протокола Secure Sockets Layer (SSL), создание собственных алгоритмов шифрования и защиту данных, передаваемых по протоколу RTMP, можно найти в таких ключевых ресурсах, как:

? документация корпорации Adobe, раздел Programming ActionScript 3.0 > Flash Player APIs > Flash Player Security;

? «Центр по вопросам безопасности» (Security Topic Center) корпорации Adobe: http. V/www. adobe. com/devnet/security/;

? технический документ корпорации Adobe, посвященный безопасности: http:// www. adobe. com/go/fp9_0_security;

? статья «Security Changes in-Flash Player 8» Денеба Мекеты (Deneb Meketa), в основном посвященная локальной безопасности: http://www. adobe. com/devnet/ flash/articles/fplayer8_security. html;

? статья «Security Changes in Flash Player 7» Денеба Мекеты, в основном посвященная файлам политики безопасности: http://www. adobe. com/devnet/flash/ articles/fplayer_security. html;

? интерактивная справка приложения Flash Player корпорации Adobe, где описываются настройки безопасности, доступные пользователям: http://www. adobe. com/support/documentation/en/flashplayer/help/index. html.

Теперь посмотрим, как безопасность приложения Flash Player влияет на загрузку содержимого и на доступ к внешним данным.

Локальная область действия, удаленная область действия и удаленные регионы

Как будет видно на протяжении этой главы, ограничения безопасности среды выполнения Flash зачастую основываются на местоположении SWF-файлов и внешних ресурсов. Оценивая местоположение ресурса с точки зрения безопасности, среда Flash различает ресурсы в удаленных местоположениях и ресурсы в локальных местоположениях.

В этой главе мы будем использовать термин «удаленная область действия» в отношении логической группы всех возможных удаленных местоположений, например Интернета. Соответственно мы будем использовать термин «локальная область действия» в отношении логической группы всех возможных локальных местопо-

ложений. Локальное местоположение — это любое местоположение, к которому может обратиться пользователь компьютера, выполняющего приложение Flash Player либо с помощью протокола file: (обычно применяется для обращения к локальной файловой системе), либо с помощью пути, соответствующему универсальному соглашению об именах (UNC — universal naming convention) (обычно применяется для обращения к компьютерам в локальной сети).

Сама по себе удаленная область действия подразделяется на различные регионы, концептуально ограничиваемые распространителями ресурсов. Мы будем называть такие регионы удаленными. В частности, удаленный регион может являться:

? доменом Интернета;

? поддоменом Интернета;

? IP-адресом, который указывает на компьютер, находящийся в удаленной области действия.

Таким образом, в соответствии с предыдущим списком:

? sitea. com и siteb. com, games. example. com и finances. example. com, 192.150.14.120 и 205.166.76.26 — это разные удаленные регионы;

? 192.150.18.117 и adobe. com — это разные удаленные регионы, несмотря на то что IP-адрес 192.150.18.117 закреплен за доменом adobe. com (поскольку для приложения Flash Player IP-адреса, заданные в числовом виде, и их эквивалентные доменные имена считаются разными).

Термины «удаленная область действия», «локальная область действия» и «удаленный регион» в настоящий момент не являются частью официальной терминологии по безопасности корпорации Adobe. Они используются в этой книге исключительно в пояснительных целях.

0-

Типы безопасности песочниц

Среда выполнения Flash присваивает статус безопасности, называемый типом безопасности песочницы, каждому SWF-файлу, открываемому или загружаемому в приложения Flash Player. Существует четыре возможных типа безопасности песочницы: удаленный (remote), локальный с поддержкой файловой системы (local — with-filesystem), локальный с поддержкой сети (local-with-networking) и локальный с установленным доверием (local-trusted). Каждый тип безопасности песочницы определяет специальный набор правил, который регламентирует возможности SWF-файла по выполнению операций с внешними источниками данных. В частности, к операциям с внешними источниками данных, которые потенциально могут быть запрещены типами безопасности песочниц, относятся:

? загрузка содержимого;

? обращение к содержимому в виде данных;

? кросс-скриптинг;

? загрузка данных;

? отправка данных на внешний адрес URL;

? обращение к камере и микрофону пользователя;

? обращение к совместно используемым локальным объектам;

? выгрузка и загрузка файлов, выбранных пользователем;

? скриптинг HTML-страницы из SWF-файла и наоборот;

? подключение к каналу LocalConnection.

В этой главе мы увидим, как каждый из перечисленных типов безопасности песочниц влияет на первые пять типов операций с внешними источниками данных из предыдущего списка. Чтобы узнать, как типы безопасности песочниц влияют на оставшиеся типы операций с внешними источниками данных, обратитесь к документации корпорации Adobe — раздел Programming ActionScript 3.0 > Flash Player APIs > Flash Player Security.

Стоит отметить, что, если операция завершилась неудачно из-за ограничений безопасности Flash Player, среда Flash сгенерирует либо ошибку SecurityError, либо выполнит диспетчеризацию события SecurityErrorEvent. SECURITY ERROR. Более подробную информацию по обработке ошибок безопасности можно найти в разд. «Обработка нарушений безопасности» ближе к концу этой главы.

Как присваиваются типы безопасности песочниц. Чтобы определить тип безопасности песочницы для конкретного SWF-файла, среда выполнения Flash сначала принимает во внимание местоположение, из которого этот SWF-файл был загружен или открыт. Всем SWF-файлам из удаленной области действия присваивается тип безопасности песочницы «удаленный». В отличие от этого, SWF-файлам из локальной области действия присваивается один из оставшихся типов безопасности песочниц — «локальный с установленным доверием», «локальный с поддержкой сети» или «локальный с поддержкой файловой системы». Конкретный тип безопасности песочницы, присваиваемый локальному SWF-файлу, зависит от двух факторов:

? была ли включена поддержка сети при компиляции SWF-файла (дополнительную информацию можно найти далее, в разд. «Выбор локального типа безопасности песочницы»);

? установлено ли явное доверие для SWF-файла (говорят, что для SWF-файла установлено явное доверие, если этот файл открыт из надежного локального местоположения; дополнительную информацию можно найти далее, в подразд. «Установка локального доверия» разд. «Выбор локального типа безопасности песочницы»).

Всем SWF-файлам из локальной области действия, для которых установлено явное доверие, присваивается тип безопасности песочницы «локальный с установленным доверием». Подобным образом, для исполняемых файлов проектора (то есть отдельных файлов, включающих SWF-файл и определенную версию приложения Flash Player) доверие установлено всегда.

Если для SWF-файлов из локальной области действия не установлено явное доверие, то им присваивается либо тип безопасности песочницы «локальный с поддержкой сети» (для SWF-файлов, которые были откомпилированы с поддержкой сети),

либо тип безопасности песочницы «локальный с поддержкой файловой системы» (для SWF-файлов, откомпилированных без поддержки сети).

Для краткости в этой главе мы будем называть SWF-файлы, которым присвоен тип безопасности песочницы «удаленный», удаленными SWF-файлами. Подобным образом мы будем использовать термины локальный SWF-файл с поддержкой файловой системы, локальный SWF-файл с поддержкой сети и локальный SWF-файл с установленным доверием в отношении SWF-файлов с типами безопасности песочниц «локальный с поддержкой файловой системы», «локальный с поддержкой сети» и «локальный с установленным доверием» соответственно.

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

^ I Чтобы определить тип безопасности песочницы SWF-файла на этапе выполнения, исполь-м$ л — 3УЙте значение переменной flash. system. Security. sandboxType внутри этого SWF-файла.

Поскольку приложение Flash Player присваивает всем SWF-файлам из удаленной области действия тип безопасности песочницы «удаленный», интернет-разработчики должны всегда учитывать ограничения данного типа безопасности песочницы.

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

В следующих разделах мы узнаем, как типы безопасности песочниц SWF-файлов влияют на возможности доступа к внешним источникам данных, а затем подробно рассмотрим механизмы (и логическое обоснование) выбора одного из трех локальных типов безопасности песочниц.

Обобщения в вопросах безопасности вредны

В оставшейся части этой главы мы будем очень подробно рассматривать конкретные операции и ограничения безопасности. При описании правил безопасности в этой книге исключены обобщения в ущерб точности, поскольку обобщения в вопросах безопасности зачастую являются источником досадных недоразумений. Помните, что, если в документации или сторонних ресурсах делаются обобщения, касающиеся вопросов безопасности приложения Flash Player, важные исключения могут остаться без должного внимания. Например, следующее утверждение большей частью является справедливым, и поэтому делается заманчивое обобщение: SWF-файл, типом безопасности песочницы которого является «локальный с поддержкой файловой системы», имеет полный доступ к локальной области действия.

Однако из этого утверждения существует множество важных исключений, включая следующие:

? локальные SWF-файлы с поддержкой файловой системы не могут подключаться к сокетам;

? локальные SWF-файлы с поддержкой файловой системы не могут загружать другие локальные SWF-файлы с поддержкой сети;

? локальные SWF-файлы с поддержкой файловой системы не могут обращаться к данным локальных SWF-файлов с установленным доверием без разрешений создателя;

? для обращения к пользовательской камере и микрофону требуется разрешение пользователя;

? пользователи для любого SWF-файла могут полностью отключить или ограничить возможность сохранения данных в совместно используемых локальных объектах.

Чтобы избежать недоразумений, если в процессе разработки вы столкнетесь с проблемой безопасности, всегда фокусируйтесь на деталях. Определите операцию, которую вы желаете выполнить, тип безопасности песочницы вашего SWF-файла и конкретные ограничения, которые накладывает данный тип безопасности песочницы на выполняемую операцию. Имея на руках эту информацию, вы сможете уверенно работать с любыми ограничениями безопасности или найти способ, чтобы обойти данные ограничения.

В этой главе не рассматриваются абсолютно все ограничения безопасности, нала-4 щ гаемые средой выполнения Flash. Чтобы определить ограничения, которые налагает 3? среда Flash на операции, не рассматриваемые в этой главе, обратитесь к разделам, посвященным данным операциям, в справочнике по языку ActionScript корпорации Adobe.

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

Ограничения на загрузку содержимого, обращение к содержимому в виде данных, кросс-скриптинг и загрузка данных

Для многих разработчиков первое знакомство с системой безопасности языка ActionScript происходит в тот момент, когда выполняемая операция блокируется из соображений безопасности. В этом разделе будет рассказано о четырех наиболее часто блокируемых внешних операциях: загрузке содержимого, обращении к содержимому в виде данных, кросс-скриптинге и загрузке данных. После этого мы рассмотрим условия, при которых происходит блокировка данных распространенных операций.

Загрузка содержимого

Загрузка содержимого подразумевает получение любого внешнего ресурса для его дальнейшего отображения или воспроизведения. По существу, операции загрузки содержимого позволяют разработчикам представлять внешнее содержимое пользователю даже в тех случаях, когда правила безопасности среды выполнения Flash запрещают программный доступ к данным этого содержимого.

Методы языка ActionScript, относящиеся к операциям «загрузки содержимого» с точки зрения безопасности, перечислены в табл. 19.1.

Таблица 19.1. Операции загрузки содержимого

Метод загрузки содержимого Тип содержимого Конкретные форматы файлов, поддерживаемые приложением Flash Player 9

flash. display. Loader. load() Изображение, файл Adobe Flash JPEG, GIF, PNG, SWF

flash. media. Sound. load() Аудио MP3

flash. net. NetStream. play() Прогрессивное видео FLV

Для удобства в этой главе время от времени используется термин «ресурсы содержимого» в отношении ресурсов, загруженных с помощью одного из методов, представленных в табл. 19.1. Стоит отметить, однако, что внешняя операция становится операцией загрузки содержимого благодаря конкретному методу, используемому для загрузки, а не типу файла данного ресурса. Например, загрузка изображения в формате JPEG с помощью метода экземпляра load ( ) класса Loader считается операцией загрузки содержимого, однако загрузка того же JPEG-изображе-ния через бинарный сокет или с помощью метода экземпляра load ( ) класса URLLoader уже не считается операцией загрузки содержимого. Это отличие существенно, поскольку к различным категориям операций применяются различные правила безопасности.

Обращение к содержимому в виде данных

Обращение к содержимому в виде данных подразумевает чтение внутренней информации ресурса содержимого, например чтение пикселов растрового изображения или спектра звука. В табл. 19.2 представлены методы языка ActionScript, которые считаются операциями «обращения к содержимому в виде данных» с точки зрения безопасности.

Таблица 19.2. Обращение к содержимому в виде данных, примеры операций

Операция Описание

Обращение к изображению через переменную экземпляра content класса Loader Получает объект Bitmap языка ActionScript, представляющий загруженное изображение

Вызов метода экземпляра draw() класса BitmapData Копирует пикселы отображаемого элемента в объект BitmapData

Вызов метода экземпляра computeSpectrum() класса SoundMixer Копирует данные текущей звуковой волны4 в объект ByteArray

Обращение к переменной экземпляра id3 класса Sound Читает метаданные в формате ID3 звукового файла

Кросс-скриптинг

Кросс-скриптинг подразумевает обращение к загруженному SWF-файлу программным путем. Многие операции языка ActionScript могут быть применены для кросс-скриптинга SWF-файла, включая следующие, но не ограничиваясь ими:

? использование переменной экземпляра content класса Loader для получения объекта, представляющего загруженный SWF-файл;

? обращение к переменным загруженного SWF-файла;

? вызов методов загруженного SWF-файла;

? привязывание к классу, определенному в загруженном SWF-файле;

? использование метода экземпляра draw ( ) класса BitmapData для копирования пикселов загруженного SWF-файла в объект BitmapData.

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

Загрузка данных

В общем смысле термин «загрузка данных» может использоваться для описания широкого спектра операций загрузки приложения Flash Player, включая загрузку файлов с сервера через метод экземпляра download ( ) класса FileRef erence, загрузку объектов с помощью приложения Flash Remoting, загрузку бинарных данных через объект Socket и т. д. Однако для текущего обсуждения (и для оставшейся части данной главы) загрузка данных подразумевает следующее:

? загрузку внешнего текста, бинарных данных или переменных с помощью метода экземпляра load ( ) класса URLLoader;

? загрузку данных с помощью метода экземпляра load ( ) класса URLStrearn.

I Чтобы узнать об ограничениях, налагаемых средой Flash на операции загрузки данных, м& л * которые не рассматриваются в этой главе, обратитесь к справочнику по языку ActionScript ——-Щ? корпорации Adobe.

Для метода экземпляра load ( ) класса URLLoader формат загружаемых данных (текст, бинарные данные или переменные) задается переменной экземпляра dataFormat класса URLLoader. К обычным текстовым форматам файлов относятся форматы XML, ТХТ и HTML. К обычным форматам бинарных данных относятся изображения, SWF-файлы и сериализованные объекты в формате ActionScript Message Format (AMF). Тем не менее бинарными данными может быть любой файл или содержимое, загруженное в объект ByteArray для дальнейшей обработки в исходном бинарном формате. Переменные загружаются в од-ном-единственном формате: преобразованные в URL-строки переменные, которые были загружены в виде пар «имя/значение» из внешнего текстового файла или сценария.

Стоит отметить, что, как и в случае с загрузкой содержимого, внешняя операция становится операцией загрузки данных благодаря конкретному методу,

используемому для загрузки, а не типу файла данного ресурса. Например, загрузка SWF-файла с помощью метода экземпляра load ( ) класса URLLoader считается операцией загрузки данных] загрузка того же SWF-файла с помощью метода экземпляра load ( ) класса Loader считается операцией загрузки содержимого.

Ограничения на загрузку содержимого, обращение к содержимому в виде данных, загрузку данных и кросс-скриптинг

Теперь, когда мы разобрались, что представляют собой операции загрузки содержимого, обращения к содержимому в виде данных, кросс-скриптинга и загрузки данных, посмотрим, как каждый из четырех типов безопасности песочниц приложения Flash Player ограничивает эти операции.

В следующих четырех таблицах (табл. 19.3-19.6) перечислены условия, при которых каждый тип безопасности песочницы разрешает или запрещает выполнять операции загрузки содержимого, обращения к содержимому в виде данных, кросс-скриптинга и загрузки данных. В каждой таблице представлены конкретные правила, устанавливаемые отдельным типом безопасности песочницы, — разрешается или запрещается использовать внешние операции, перечисленные в крайнем левом столбце, для обращения к ресурсам, перечисленным в оставшихся столбцах таблицы.

Как видно из таблиц, некоторые операции допускаются только при наличии разрешения создателя или распространителя. Разрешение создателя подразумевает, что SWF-файл включает надлежащий вызов статического метода allowDomain ( ) класса Security(или, вpeдкиxcлyчaяx, вызoвмeтoдaallowInsecureDomain ( ) ).Разрешение распространителя подразумевает, что распространитель ресурса сделал доступным надлежащий файл междоменной политики безопасности. Более подробную информацию можно найти далее, в разд. «Разрешения создателя (allowDomain( ))» и «Разрешения распространителя (файлы политики безопасности)».

Как видно из табл. 19.3-19.6, загрузка содержимого разрешается в большем количестве ситуаций по сравнению с загрузкой содержимого в виде данных, кросс-скриптингом и загрузкой данных. Например, приложению может быть дано разрешение на загрузку и отображение растрового изображения, но запрещен доступ к исходным пиксельным данным этого изображения. Подобным образом приложению может быть дано разрешение на загрузку и отображение внешнего SWF-файла, но может требоваться разрешение на кросс-скриптинг этого SWF-файла.

Стоит отметить, что в табл. 19.3-19.6 рассмотрены разрешения только для одного направления взаимодействия, когда SWF-файл загружает или обращается к внешнему ресурсу. В этих таблицах не описано обратное направление взаимодействия, когда загруженный SWF-файл взаимодействует с SWF-файлом, загрузившим его. Информацию по двунаправленному взаимодействию между SWF-файлами можно найти в разделе Programming ActionScript 3.0 > Flash Player APIs > Flash Player Security > Cross-scripting документации корпорации Adobe.

В табл. 19.3 перечислены правила, устанавливаемые типом безопасности песочницы «удаленный». Здесь выражение «регион происхождения SWF-файла» подразумевает удаленный регион, из которого был открыт или загружен данный SWF-файл. Например, если файл hiscores. swf загружается из удаленного местоположения http://coolgames. com/hiscores. swf, то регионом происхождения файла hiscores. swf является coolgames. com (дополнительные сведения по удаленным регионам можно найти в разд. «Локальная область действия, удаленная область действия и удаленные регионы»).

В табл. 19.3 демонстрируются следующие ключевые правила типа безопасности песочницы «удаленный».

? Операции загрузки содержимого, обращения к содержимому в виде данных, кросс-скриптинга и загрузки данных не могут использоваться вместе с ресурсами из локальной области действия.

? Все ресурсы из всей удаленной области действия могут загружаться в виде содержимого.

? Операции загрузки содержимого, обращения к содержимому в виде данных, кросс-скриптинга и загрузки данных могут использоваться для всех ресурсов из региона происхождения SWF-файла.

? К ресурсам удаленной области действия, находящимся за пределами региона происхождения SWF-файла, можно обращаться как к данным или загружать их как данные, если установлено соответствующее разрешение распространителя.

? Для SWF-файлов из удаленной области действия, находящихся за пределами региона происхождения SWF-файла, может быть выполнен кросс-скриптинг, если установлено соответствующее разрешение создателя.

Таблица 19.3. Тип безопасности песочницы «удаленный», допустимые и запрещенные операции

Операция Локальная область действия Ресурсы удаленной области действия из региона происхождения SWF-файла Ресурсы удаленной области действия, находящиеся за пределами региона происхождения SWF-файла

Загрузка содержимого Запрещается Допускается Допускается

Обращение к содержимому в виде данных Запрещается Допускается Допускается только по разрешению распространителя

Кросс-скриптинг Запрещается Допускается Допускается только по разрешению создателя

Загрузка данных Запрещается Допускается Допускается только по разрешению распространителя

В табл. 19.4 перечислены следующие ключевые правила, устанавливаемые типом безопасности песочницы «локальный с поддержкой файловой системы».

? Операции загрузки содержимого, обращения к содержимому в виде данных, кросс-скриптинга и загрузки данных не могут использоваться вместе с ресурсами из удаленной области действия.