Руководство по actionscript. часть 3, стр. 100

Чтобы загрузить фотографию, Грейм использует следующий код (обратите внимание, что вызывать метод Security. loadPolicyFile ( ) не обязательно, поскольку Грейм разместил файл политики безопасности в используемом по умолчанию местоположении файла политики безопасности).

var loaderContext = new LoaderContext( ): loaderContext. checkPolicyFile = true: loader. load(

new URLRequest(«http://photos.1otterylotterylottery. com/randompiс. pi»). loaderContext):

В результате выполнения приведенного кода приложение Flash Player загружает файл http://photosJotterylotterylottery. com/crossdomain. xml, находит в нем требуемое разрешение, загружает фотографию, возвращаемую сценарием randomi с. pi, и после этого разрешает приложению partyhat. swf обратиться к пикселам загруженной фотографии.

После загрузки фотографии приложение partyhat. swf благополучно обращается к ее данным. Например, вот код, используемый Греймом для вызова метода приложения pa г t yha t. s wf, который добавляет шляпу для вечеринок к загруженной фотографии (стоит отметить, что для обращения к объекту Bitmap загруженного изображения loader. content требуется разрешение):

addHat(1oader. content):

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

Использование файла политики безопасности для разрешения сокетных соединений

Чтобы разрешить сокетные соединения с помощью файла политики безопасности, используйте следующую общую последовательность действий.

1. Создайте файл политики безопасности.

2. Сделайте так, чтобы этот файл был доступен через сокетный сервер или HTTP-сервер, запущенный в том же домене или для того же IP-адреса, с которым планируется установить сокетное соединение.

Описанные шаги подробно рассматриваются в следующих трех разделах.

Создание файла политики безопасности

Файлы политики безопасности, разрешающие установку сокетных соединений, в основном имеют такой же синтаксис, как и файлы политики безопасности, разрешающие выполнение операций загрузки данных и обращения к содержимому в виде данных. Однако в файлах первого типа тег содержит дополнительный атрибут to-ports, как показано в следующем коде:




SYSTEM «http://www. adobe. com/xml/dtds/cross-domain-policy. dtd»>



Атрибут to-ports определяет порты, к которым может подключаться SWF-файл из источника доменИли1Р. Порты можно задавать по отдельности (разделяя значения запятыми) или диапазонами (разделяя значения символом -). Например, приведенный далее файл политики безопасности устанавливает следующие разрешения:

? SWF-файлы из источника examplel. com могут подключаться к портам 9100 и 9200;

? SWF-файлы из источника example2.com могут подключаться к портам в диапазоне от 10 000 до И 000.

Руководство по actionscript. часть 3, стр. 101









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

I Поскольку порты ниже 1024 считаются привилегированными, файл политики безопас-А т ности, получаемый через порт 1024 или выше, не сможет разрешить доступ к портам ц»У ниже 1024, даже если они будут указаны явно.

Например, если получение следующего файла политики безопасности осуществляется через порт 2000, SWF-файлам с сайта example3.com будет дано разрешение на подключение ко всем портам выше или равным 1024.


SYSTEM «http://www. adobe. com/xml /dtds/сross-domai n-poli cy. dtd»>



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

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


SYSTEM «http://www,.adobe. com/xml/dtds/cross-domain-pol icy. dtd»>



Когда получение файла политики безопасности осуществляется через сокет, атрибут to-ports является обязательным. Если этот атрибут не указан, то доступ будет запрещен ко всем портам.

Руководство по actionscript. часть 3, стр. 102

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

Получение файла политики безопасности через сокет

Файлы политики безопасности, разрешающие сокетные соединения, могут передаваться либо непосредственно через сокет, либо по протоколу HTTP. Файлы политики безопасности, передаваемые через сокет, должны размещаться в том же домене или на том же IP-адресе, с которым планируется устанавливать соединение. При этом можно использовать либо порт, с которым устанавливается соединение, либо другой порт. В любом случае сервер, обслуживающий порт, через который передается файл политики безопасности, должен общаться с приложением Flash Player с помощью очень простого протокола получения файла политики безопасности. Протокол состоит из одного тега , который отправляется приложением Flash Player через сокет, когда оно желает загрузить файл политики безопасности, разрешающий сокетное соединение. В ответ сокетный сервер должен отправить приложению Flash Player текст файла политики безопасности в формате ASCII вместе с нулевым байтом (то есть пустым символом таблицы ASCII) и после этого закрыть соединение.

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

Предположим, что многопользовательский игровой сервер, размещенный на сайте site-a. com, обрабатывает игровые запросы и запросы на получение файла политики безопасности на порте 3000. Файл политики безопасности этого сервера разрешает доступ для источников www. site-b. com и site-b. com, как показано в следующем коде:




SYSTEM «http://www. adobe. com/xiTil/dtds/cross-doiTiain-policy. dtd»>





Чтобы подключиться к порту 3000 сайта site-a. com, любой SWF-файл, загруженный из источника www. site-b. com или site-b. com, может использовать следующий код:

var socket:Socket = new Socket( ): try { .

socket. connect(«site-a. com». 3000): } catch (e:SecurityError) { trace(«Connection problem!»): trace(e. message):

}

При выполнении предыдущего кода перед тем, как будет разрешено требуемое подключение к порту 3000, приложение Flash Player автоматически создает отдельное

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

Руководство по actionscript. часть 3, стр. 103

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

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

Securi ty.1oadPoli суFi1е(«xmlsocket://доменИли1Р:номерПорта»):

Здесь доменИли1Р — это доменное имя или IP-адрес сервера, а номерПорта — номер порта, через который будет получен файл политики безопасности. Повторим, что IP-адреса, заданные в числовом виде, и их эквивалентные доменные имена для приложения Flash Player считаются разными. В предыдущем коде обратите внимание на обязательное использование протокола xml socket: //. Название протокола описывает тип подключения, используемого для получения файла политики безопасности, а не тип подключения, который разрешает этот файл политики безопасности.

Файл политики безопасности, загруженный с помощью протокола xmlsocket://, разрешает подключения с использованием обоих классов Socket и XMLSocket, а не только с использованием класса XMLSocket.

Отправив инициированный вручную запрос на получение файла политики безопасности, можно сразу же отправлять последующий запрос на подключение к желаемому порту. Предположим, что на порте 1021 сайта site-c. com запущен простой сервер, обслуживающий запросы на получение файла политики безопасности, и что файл политики безопасности сайта site-c. com разрешает установление соединений к порту 25 из источников site-d. com и www. site-d. com. Вот файл политики безопасности:


SYSTEM «http://www. adobe. com/xml/dtds/cross-domain-policy. dtd»>





Чтобы подключиться к порту 25 сайта site-c. com, любой SWF-файл, загруженный из источников site-d. com или www. site-d. com, может использовать следующий код. Обратите внимание, что SWF-файл запрашивает сокетное соединение с портом 25 сразу после отправки запроса на получение файла политики безопасности через порт 1021. Приложение Flash Player терпеливо дожидается окончания загрузки файла политики безопасности перед тем, как продолжить подключение к порту 25.

// Загружаем файл политики безопасности вручную Security.1oadPoli cyFi1e(«xmlsocket://site-c. com:1021″); var socket:Socket = new Socket( ); try {

// Пытаемся установить соединение (сразу после того, как был запрошен файл // политики безопасности) socket. connect(«site-c. com», 25); } catch (e:SecurityError) { trace(«Connection problem!»); trace(e. message):

}

При выполнении предыдущего кода приложение Flash Player перед тем, как разрешить запрашиваемое подключение к порту 25, устанавливает отдельное подключение к порту 1021 и отправляет сообщение серверу, прослушивающему этот порт. Сервер отправляет в ответ файл политики безопасности сайта site-c. com и после этого закрывает подключение. В списке разрешенных регионов этого файла политики безопасности содержится источник SWF-файла, устанавливающего соединение, поэтому установление соединения с портом 25 может быть продолжено.

Руководство по actionscript. часть 3, стр. 104

Теперь рассмотрим альтернативный способ для разрешения сокетного соединения: файл политики безопасности, передаваемый по протоколу HTTP.

Получение файла политики безопасности по протоколу HTTP

Приложение Flash Player до версии 7.0.19.0 требовало, чтобы файлы политики безопасности, разрешающие сокетные соединения, передавались по протоколу HTTP. Язык ActionScript 3.0, в основном для обратной совместимости, продолжает поддерживать механизм разрешения сокетных соединений посредством файлов политики безопасности, передаваемых по протоколу HTTP. Тем не менее, чтобы разрешить сокетное соединение, файл политики безопасности, передаваемый по протоколу HTTP, должен удовлетворять следующим требованиям:

? называться crossdomain. xml;

? размещаться в корневой директории веб-сервера;

? передаваться через порт 80 домена или IP-адреса, с которым устанавливается желаемое сокетное соединение;

? в языке ActionScript 3.0 файл должен загружаться вручную с помощью метода Security. loadPolicyFile ( ).

Более того, в файлах политики безопасности, передаваемых по протоколу HTTP, не используется атрибут to-ports. Вместо этого доступ предоставляется ко всем портам, большим или равным 1024.

I Файл политики безопасности, передаваемый по протоколу HTTP, не может разрешать м? s „ сокетные подключения к портам ниже 1024 (однако стоит отметить, что до появления приложения Flash Player версии 9.0.28.0 это правило не действовало из-за ошибки).

Чтобы получить разрешение на установление заданного сокетного соединения из файла политики безопасности, передаваемого по протоколу HTTP, необходимо вручную загрузить этот файл до того, как будет предпринята попытка установить соединение, как показано в следующем обобщенном коде:

Security. 1 oadPol icyFi 1 e( «http: // доменИли1Р/crosstiomin. xml»);

В предыдущем коде доменИли1Р — это точное имя домена или точный IP-адрес желаемого сокетного соединения.

Отправив запрос на получение файла политики безопасности по протоколу HTTP, можно сразу же отправлять последующий запрос на подключение к желаемому порту. Предположим, что у сайта site-a. com есть следующий файл политики безопасности, размещенный на веб-сервере по адресу http://site-a. com/crossdomain. xml. Этот файл политики безопасности разрешает доступ для источников site-b. com и www. site-b. com:


SYSTEM «http://www. adobe. com/xml/dtds/cross-domain-policy. dtd»>





Чтобы подключиться к порту 9100 сайта site-a. com, любой SWF-файл, загруженный из источников site-b. com или www. site-b. com, может использовать следующий код.

Руководство по actionscript. часть 3, стр. 105

// Запрашиваем файл политики безопасности по протоколу HTTP перед попыткой // установления соединения

Security. loadPolicyFile(«http://site-a. com/crossdomai п. xml»): var socket:Socket = new Socket( ): try {

// Пытаемся установить соединение (сразу после того, как был отправлен // запрос на получение файла политики безопасности socket. connect(«site-a. com», 9100); } catch (e:SecurityError) { trace(«Connection problem!»); trace(e. message);

}

При выполнении предыдущего кода приложение Flash Player перед тем, как разрешить запрашиваемое подключение к порту 9100, загружает файл политики

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

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

Разрешения создателя (allowDomainf))

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

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

В этой книге не рассматриваются операции скриптинга SWF-файлов из HTML-файлов. А л Подробную информацию о безопасности и операциях скриптинга SWF-файлов из HTML-ц>У файлов можно найти в разделах, описывающих статические методы allowDomain()

и allowInsecureDomain(), справочника по языку ActionScript корпорации Adobe.

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

Securi ty. allowDomai n(«site-b. com»);

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

Руководство по actionscript. часть 3, стр. 106

1 В отличие от разрешений распространителя, разрешения создателя передаются вместе

A ti с SWF-файлом, для которого они установлены.

Метод allowDomain ( ) имеет следующий обобщенный вид:

Security. allowDomain Гдоиеяйли/РГ’, «доменИли! Р2″…. «доменИли! Рп»)

где «доменИли1Р1″ , «доменИли1Р2″ . . . «доменИли1Рп» — это список строк, содержащих доменные имена или IP-адреса разрешенных источников. SWF-файл, загруженный из разрешенного источника, может выполнять операции кросс-скриптинга над SWF-файлом, вызвавшим метод allowDomain ( ).

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

Securi ty. al1owDomai n(«*»);

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

Тем не менее, когда символ * используется в параметрах метода allowDomain ( ), он не может применяться в качестве подстановочного символа поддомена (это слегка необычное поведение отличается от использования группового символа в файлах политики безопасности). Например, следующий код не разрешает доступ для всех поддоменов сайта example. com:

// Внимание: Не используйте этот код! Подстановочные символы поддоменов // не поддерживаются.

Securi ty. al1owDomai n(«*.example. com»);

Сразу после вызова метода allowDomain ( ) любой SWF-файл из разрешенного источника может немедленно приступать к выполнению разрешенных операций. Предположим, что телевизионная сеть использует универсальное приложение для воспроизведения анимации, которое размещается на сайте www. sometvnetwork. com. Проигрыватель загружает анимационные ролики в формате SWF с сайта animation. sometvnetwork. com. Для управления воспроизведением загруженных роликов проигрыватель вызывает основные методы класса MovieClip (play ( ), stop ( ) и т. д.) над этими роликами. Поскольку проигрыватель и анимационные ролики загружаются из различных поддоменов, проигрыватель должен получить разрешение на вызов методов класса MovieCl ip над роликами. Таким образом, каждый конструктор основного класса анимационного ролика включает следующую строку кода, которая предоставляет необходимое разрешение проигрывателю:

Securi ty. allowDomai n(«www. sometvnetwork. com», «sometvnetwork. com»);

Обратите внимание, что, поскольку проигрыватель может быть открыт из источника www. sometvnetwork. com или sometvnetwork. com, анимационные файлы разрешают доступ для обоих доменов. Для загрузки анимационных роликов проигрыватель использует следующий код:

var loader-.Loader = new Loader( ); loader. load(

new URLRequest(«http://animation. sometvnetwork. com/названиеАнимации. swf»));

Сразу после выполнения конструктора основного класса анимационного ролика проигрыватель может приступать к управлению загруженным роликом.

Руководство по actionscript. часть 3, стр. 107

I Чтобы гарантировать, что разрешения на выполнение операций кросс-скриптинга будут пре-*v j „ доставлены фазу после инициализации БУУРфайла, вызывайте метод Security. allowDomain() Ъ-У внутри метода-конструктора основного класса этого SWF-файла.

SWF-файл может определить, есть ли у него разрешение на выполнение операций кросс-скриптинга над загруженным SWF-файлом, проверив значение переменной childAllowsParent объекта Loader Info загруженного файла.

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

Разрешение операций кросс-скриптинга над SWF-файлами, загружаемыми по протоколу HTTPS, для файлов, загружаемых по протоколу HTTP. Когда SWF-файл загружается по протоколу HTTPS, приложение Flash Player запрещает вызов метода allowDomain ( ), разрешающий доступ для источников, не использующих протокол HTTPS. Тем не менее разработчики, желающие разрешить доступ для источников, не использующих протокол HTTPS, из SWF-файла, загружаемого по протоколу HTTPS, могут, соблюдая должную осторожность, использовать метод Security. allowInsecureDomain ( ).

Разрешение доступа для источника, не использующего протокол HTTPS, из SWF-файла, загружаемого по протоколу HTTPS, считается угрожающе опасным и категорически не рекомендуется.

Синтаксис и использование метода allowInsecureDomain ( ) такие же, как и у метода allowDomain ( ), рассмотренного в предыдущем разделе. Единственное отличие заключается в том^ что метод allowInsecureDomain ( ) позволяет разрешить доступ для источников, не использующих протокол HTTPS, из SWF-файла, загружаемого по протоколу HTTPS. В подавляющем большинстве ситуаций для предоставления разрешений создателя следует использовать метод allowDomain ( ) вместо allowInsecureDomain ( ). Найти описание особых ситуаций, требующих использования метода allowInsecureDomain ( ), можно в разделе, посвященном методу Security. allowInsecureDomain ( ), справочника по языку ActionScript корпорации Adobe.

Импортирующая загрузка

В гл. 28 будет рассказано, как SWF-файл родителя может особым образом загрузить SWF-файл ребенка, что позволит родителю непосредственно использовать классы ребенка так, будто они определены в родителе. Эта методика требует, чтобы SWF-файл родителя импортировал классы SWF-файла ребенка в свой домен приложения. Рассмотрим базовый код, который должен включать SWF-файл родителя (обратите внимание на использование переменной экземпляра applicationDomain класса LoaderContext):

var loaderContext:LoaderContext = new LoaderContext( ):

1oaderContext. appli cati onDomai n = Appli cati onDomai n. currentDomai n;

var loader:Loader = new Loader( ):

loader, load (new URLRequest (» ребенок, svif»), loaderContext):

При выполнении приведенного кода попытка импортировать классы ребенка в домен приложения родителя будет заблокирована системой безопасности приложения Flash Player в следующих ситуациях:

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

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

Руководство по actionscript. часть 3, стр. 108

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

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

2. Если файл политики безопасности находится не в применяемом по умолчанию местоположении, родитель должен загрузить его вручную, используя метод Security. loadPolicyFile ( ), опять же как было описано в разд. «Разрешения распространителя (файлы политики безопасности)».

3. При загрузке SWF-файла ребенка SWF-файл родителя должен передать в метод load ( ) объект LoaderContext, переменной securityDomain которого присвоено значение flash. system. SecurityDomain. currentDomain.

Предположим, что на сайте site-a. com размещен следующий используемый по умолчанию файл политики безопасности, который разрешает доступ для источников site-b. com и www. site-b. com.


SYSTEM «http://www. adobe. com/xml/dtds/cross-domain-policy. dtd»>





Теперь предположим следующее: файл site-b. com/parent. swf желает импортировать классы файла site-a. com/child. swf в свой домен приложения. Для этого файл site-b. com/parent. swf использует следующий код (обратите внимание, что метод Security. loadPolicyFile ( ) не используется, поскольку файл политики безопасности находится в используемом по умолчанию местоположении файла политики безопасности):

var loaderContext:LoaderContext = new LoaderContext( ):

1oaderContext. appli cati onDomai n = Applicati onDomai n. currentDomai n;

loaderContext. securityDomain = SecurityDomain. currentDomain:

1 oader.1oad(new URLRequest(«http://site-a. com/chi1d. swf»), 1oaderContext):

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

Руководство по actionscript. часть 3, стр. 109

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

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

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

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

Механизмы обращения к классам в загруженных SWF-файлах рассматриваются в гл. 28 и 31.

Обработка нарушений безопасности

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

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

В отличие от этого, диспетчеризация события SecurityErrorEvent. SECURITY_ERROR происходит в том случае, когда после ожидания завершения некоторой асинхронной задачи среда Flash определяет, что было нарушено правило безопасности. Например, когда локальный SWF-файл с поддержкой сети использует метод экземпляра load ( ) класса URLLoader для загрузки файла из удаленной области действия,

среда Flash должна асинхронно проверить наличие подходящего файла политики безопасности, разрешающего операцию загрузки. Если операция проверки файла политики безопасности завершится неудачей, среда Flash выполнит диспетчеризацию события SecurityErrorEvent. SECURITY_ERROR (заметьте — не исключение SecurityError).

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

| Чтобы убедиться, что никакие нарушения безопасности не остались незамеченными, м?, 4 п всегда проверяйте код в отладочной версии приложения Flash Player. _ flft_

Для обработки ошибок безопасности используется инструкция try/catch/ finally. Для обработки событий SecurityErrorEvent. SECURITY_ERROR применяются приемники событий. Например, следующий код генерирует исключение SecurityError, пытаясь установить сокетное подключение к порту выше 65 535. При возникновении ошибки код добавляет сообщение о причине ее возникновения в объект TextField, отображаемый на экране.

var socket:Socket = new Socket( ): try {

socket-.connectCexample. com», 70000): } catch (e:SecurityError) { output. appendText(«Connection problem!\n»); output. appendText(e. message):

}

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



Полезные ссылки
Случайные записи
  • 02.06.2010">Самоучитель по креативному веб-дизайну. Книга 3, стр.116
  • 26.08.2010">Классификация сайтов для дизайнера.
  • 28.02.2010">Где найти и скачать иконки?
  • 11.03.2011">Руководство по actionscript. часть 4, стр. 013
  • 05.11.2012">Gmail стал самым популярным почтовым сервисом в мире
  • 26.02.2011">Руководство по actionscript. часть 6, стр. 069
  • 09.03.2011">Руководство по actionscript. часть 4, стр. 068
  • 17.05.2010">Самоучитель по креативному веб-дизайну. Книга 2, стр.132
  • 26.02.2011">Руководство по actionscript. часть 6, стр. 054
  • 06.07.2011">Хoрoший дизaйн сайта инструмент для достижения прибыли.
  • 27.02.2011">Руководство по actionscript. часть 6, стр. 023
  • 15.06.2010">Самоучитель по креативному веб-дизайну. Книга 4, стр.57
  • 18.05.2010">Самоучитель по креативному веб-дизайну. Книга 2, стр.54
  • 03.06.2010">Самоучитель по креативному веб-дизайну. Книга 3, стр.44
  • 17.05.2012">«Лаборатория Касперского»: спамеры нацелились на геймеров и пользователей Facebook
Опрос

Какие цвета вы предпочитаете?

View Results

Loading ... Loading ...