Security  - AS3

Определяет, каким образом проигрыватель Flash Player или приложение AIR выбирает домен для работы с такими параметрами Flash Player, как разрешения на доступ к камере и микрофону, квоты хранилища, а также параметры хранения постоянных общих объектов. Чтобы в SWF-файле использовались настройки, аналогичные тем, которые использовались в приложении Flash Player 6, задайте для exactSettings значение false.

В Flash Player 6 домен, используемый для этих параметров проигрывателя, выбирался исходя из конечной порции домена SWF-файла. Если домен SWF-файла включает больше двух сегментов, например www.example.com, первый сегмент домена (www) удаляется, и используется оставшаяся часть домена: example.com. Так, в Flash Player 6 и www.example.com и store.example.com используют example.com в качестве домена для этих параметров. Подобным образом, и www.example.co.uk и store.example.co.uk используют example.co.uk в качестве домена для параметров. В Flash Player 7 и более поздних версиях параметры проигрывателя по умолчанию выбираются в соответствии с точным доменом SWF- файла. Например SWF-файл с www.example.com будет использовать параметры проигрывателя для www.example.com, а SWF-файл с store.example.com — отдельные параметры для store.example.com.

Когда Security.exactSettings имеет значение true, Flash Player ли AIR использует точные домены для параметров проигрывателя. По умолчанию exactSettings имеет значение true. Изменение значения по умолчанию свойства exactSettings необходимо выполнить до появления событий, требующих выбора параметров проигрывателя Flash Player или AIR, таких как использование камеры или микрофона или получение постоянного общего объекта.

Если ранее был опубликован SWF-файл версии 6, из которого были созданы постоянные общие объекты, и теперь эти объекты необходимо получить из этого SWF-файла после перехода к версии 7 или более поздней или из другого SWF-версии 7 или более поздней, необходимо задать для Security.exactSettings значение false перед вызовом метода SharedObject.getLocal().

Часть домена HTML-страницы, содержащей swf.

Из соображений безопасности метод не возвращает полный URL-адрес, а возвращает только домен страницы, например http://www.example.com. Если этот SWF не содержится в HTML-странице или не может получить доступ к домену страницы из соображений безопасности, это свойство возвращает строку (undefined).

Показывает тип изолированной программной среды безопасности, в которой работает вызывающий файл.

Для Security.sandboxType можно устанавливать одно из следующих значений.

• remote (Security.REMOTE): этот файл загружается с URL-адреса в Интернете и используется в соответствии с правилами изолированной программной среды на основе домена.
• localWithFile (Security.LOCAL_WITH_FILE): этот файл является локальным файлом, не является доверенным для пользователя и не публиковался с сетевым наименованием. Файл может считывать информацию из локальных источников данных, но не может обмениваться данными через Интернет.
• localWithNetwork (Security.LOCAL_WITH_NETWORK): этот SWF-файл является локальным файлом, не является доверенным для пользователя и публиковался с сетевым наименованием. SWF-файл может обмениваться данными через Интернет, но не может считывать информацию из локальных источников данных.
• localTrusted (Security.LOCAL_TRUSTED): этот SWF-файл является локальным файлом, пользователь сделал его доверенным с помощью диспетчера настроек проигрывателя Flash Player или файла конфигурации FlashPlayerTrust. Файл может считывать информацию из локальных источников данных и обмениваться данными через Интернет.
• application (Security.APPLICATION): файл работает в приложении AIR и был установлен с пакетом (файлом AIR) для этого приложения. По умолчанию файлы в изолированной программной среде безопасности приложения AIR могут выполнять перекрестные сценарии с любым файлом из любого домена (в то время как файлы за ее пределами могут не иметь разрешения на выполнение перекрестных сценариев с файлом AIR). По умолчанию файлы в изолированной программной среде безопасности приложения AIR могут загружать содержимое и данные из любого домена.

Дополнительные сведения о безопасности см. в разделе центра разработчиков Flash Player Безопасность.

Связанные элементы API

Обеспечивает файлам SWF в указанных доменах доступ к объектам и переменным в файле SWF, содержащем вызовallowDomain().

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

Если два SWF-файла размещаются на одном домене, например http://mysite.com/swfA.swf и http://mysite.com/swfB.swf, то swfA.swf может анализировать и модифицировать переменные, объекты, свойства, методы и прочее в swfB.swf и наоборот. Это называется выполнением сценариев между роликами или выполнением перекрестных сценариев.

Если два SWF-файла находятся в разных доменах, например http://siteA.com/swfA.swf и http://siteB.com/siteB.swf, то по умолчанию Flash Player не позволяет swfA.swf выполнять сценарии, связанные с swfB.swf, и наоборот. SWF-файл предоставляет доступ к SWF-файлам из других доменов путем вызова Security.allowDomain(). Это называется выполнением междоменных сценариев. Вызывая Security.allowDomain("siteA.com"), siteB.swf дает siteA.swf разрешение на выполнение сценариев.

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

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

Кроме защиты SWF-файлов от междоменного создания сценариев другими SWF-файлами, в приложении Flash Player предусмотрена защита SWF-файлов от междоменного создания сценариев с использованием файлов HTML. Создание сценариев из файлов HTML в SWF-файлах может выполняться с использованием функций браузеров более ранних версий, например SetVariable, или обратных вызовов в функции ExternalInterface.addCallback(). Если создание сценариев из файлов HTML в SWF-файлах выполняется между доменами, вызываемый SWF-файл должен обращаться к методу allowDomain(), как и в том случае, если вызывающей стороной является SWF-файл, или произойдет сбой операции.

При указании IP-адреса в качестве параметра для allowDomain() доступ всем сторонам, расположенным по указанному IP-адресу, предоставлен не будет. Благодаря этому можно разрешить доступ только стороне, которая содержит указанный IP-адрес в своем URL-адресе, а не имя домена, указывающее на этот IP-адрес.

Различия, характерные для версий

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

Версиями, в которых можно управлять поведением Flash Player, являются версии SWF (опубликованные версии SWF-файла), но не версии приложения Flash Player. Например, когда в приложении Flash Player 8 воспроизводится SWF-файл, опубликованный для версии 7, применяется поведение, характерное для версии 7. Такой подход позволяет убедиться в том, что поведение Security.allowDomain() в развернутых SWF-файлах не изменится из-за обновлений проигрывателя.

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

В следующих параграфах приводятся дополнительные сведения об изменениях безопасности Flash Player, в которых задействован метод Security.allowDomain().

Версия 5. Ограничения на междоменное выполнение сценариев не накладываются.

Версия 6. Вводится защита междоменного выполнения сценариев. По умолчанию в приложении Flash Player междоменное выполнение сценариев запрещено; его можно разрешить с помощью метода Security.allowDomain(). Чтобы определить, находятся ли оба файла в одном домене, в приложении Flash Player используется сверхобласть каждого файла, которая представляет собой точное имя узла из URL-адреса файла, за исключением первого сегмента, но состоит как минимум из двух сегментов. Например, сверхобластью узла www.mysite.com является mysite.com. SWF-файлы с узлов www.mysite.com и store.mysite.com могут осуществлять перекрестное выполнение сценариев без вызова метода Security.allowDomain().

Версия 7. Соответствие сверхобластей заменено на точное соответствие доменов. Двум файлам разрешено перекрестное выполнение сценариев, только если имена узлов в их URL-адресах полностью идентичны; в противном случае необходимо вызвать метод Security.allowDomain(). По умолчанию файлам, загруженным с URL-адресов, отличных от HTTPS, запрещено выполнять сценарии в файлах, загруженных с URL-адресов HTTPS, даже если файлы загружены с полностью идентичного домена. Благодаря этому ограничению можно защитить файлы HTTPS, поскольку файл, отличный от HTTPS, подвержен изменениям при загрузке, а злоумышленно измененный файл, отличный от HTTPS, может повредить файл HTTPS, который в противном случае защищен от такого повреждения. Метод Security.allowInsecureDomain() используется, чтобы разрешить вызываемым SWF-файлам HTTPS свободно отключать это ограничение, но метод Security.allowInsecureDomain() использовать не рекомендуется.

Версия 8. Изменения представлены в двух основных областях:

• Обращение к методу Security.allowDomain() теперь позволяет осуществлять операции междоменного выполнения сценариев, только если вызываемый SWF-файл является SWF-файлом, вызывающим метод Security.allowDomain(). Другими словами, доступ предоставляется только SWF-файлу, который вызывает метод Security.allowDomain(). В предыдущих версиях обращение к методу Security.allowDomain() позволяло разрешить перекрестное выполнение сценариев, в то время как вызываемый SWF-файл мог быть любым SWF-файлом в том же домене, что и SWF-файл, вызывающий метод Security.allowDomain(). Ранее обращение к методу Security.allowDomain() позволяло открыть весь домен вызывающего SWF-файла.
• Добавлена поддержка значений подстановочного символа в методах Security.allowDomain("*") и Security.allowInsecureDomain("*"). Использование значения подстановочного символа (*) позволяет разрешить операции перекрестного выполнения сценариев, если вызываемый файл является любым файлом, загруженным с любого узла. Подстановочный символ можно рассматривать как глобальное предоставление прав. Права доступа, предоставленные с использованием подстановочного символа, необходимы для включения определенных операций в соответствии с правилами безопасности локального файла. В частности, чтобы локальный SWF-файл с правами сетевого доступа мог выполнять сценарий в SWF-файле в Интернете, вызываемый интернет-файл SWF должен обращаться к методу Security.allowDomain("*"), в котором указано, что источник локального SWF-файла неизвестен. (Если Интернет-файл SWF загружен с использованием адреса URL HTTPS, вместо этого интернет-файл SWF должен обращаться к методу Security.allowInsecureDomain("*").)

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

В этой ситуации можно использовать свойство url объекта URLRequest, переданного в метод Loader.load(). Например, если загружен дочерний SWF-файл в родительский SWF-файл, можно получить доступ к свойству contentLoaderInfo объекта Loader для родительского SWF-файла:

Security.allowDomain(loader.contentLoaderInfo.url)

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

Кроме того, может возникнуть противоположная ситуация; то есть можно создать дочерний SWF-файл, в котором необходимо разрешить выполнение сценария родительским файлом, но при этом домен родительского файла неизвестен. В этой ситуации можно получить доступ к свойству loaderInfo экранного объекта, который является корневым объектом SWF-файла. В дочернем SWF-файле необходимо вызвать Security.allowDomain( this.root.loaderInfo.loaderURL). Нет необходимости ждать загрузки родительского SWF-файла — он уже будет загружен к тому времени, когда будет проходить загрузка дочернего файла.

При публикации для Flash Player 8 или более поздней версии можно также решить эти ситуации, вызвав Security.allowDomain("*"). Однако это решение может быть опасным, поскольку при этом доступ к вызывающему SWF-файлу разрешается любому SWF-файлу из любого домена. Использование свойства _url является более безопасным.

Дополнительные сведения о безопасности см. в разделе центра разработчиков Flash Player Безопасность.

Параметры

Связанные элементы API

Обеспечивает файлам SWF и HTML в указанных доменах доступ к объектам и переменным в вызывающем файле SWF, размещенном на сервере с использованием протокола HTTPS.

В проигрывателе Flash Player этот метод allowInsecureDomain() предусмотрен для увеличения гибкости, но вызывать его не рекомендуется. Размещение файлов с использованием HTTPS обеспечивает несколько факторов защиты для вас и ваших пользователей, а вызов метода allowInsecureDomain ослабляет один из этих факторов.

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

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

Используйте allowInsecureDomain() только для разрешения выполнения сценариев файлов без HTTPS для файлов с HTTPS. Используйте этот метод для разрешения сценариев, когда вызывающий файл без HTTPS и вызываемый файл с HTTPS находятся на одном домене, например, если SWF-файл с адресом http://mysite.com хочет выполнить сценарий для SWF-файла с адресом https://mysite.com. Не используйте этот метод для разрешения сценариев между файлами без HTTPS, между файлами с HTTPS, а также для выполнения сценариев файла с HTTPS для файла без HTTPS. В таких ситуациях следует использовать метод allowDomain().

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

Предположим, выполняется построение web-сайта электронной коммерции, состоящего из двух компонентов: каталога, защита которого не требуется, поскольку в нем содержится только общедоступная информация; и компонента корзины для покупок или оформления, который должен быть защищенным для обеспечения безопасности финансовой и личной пользовательской информации. Предположим, рассматривается возможность обслуживания каталога с узла http://mysite.com/catalog.swf, а корзины — с узла https://mysite.com/cart.swf. Единственным требованием для web-сайта является обеспечение защиты, чтобы третья сторона не могла украсть номера пользовательских кредитных карт, воспользовавшись уязвимыми местами в архитектуре защиты.

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

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

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

Однако предположим, что необходимо разрешить кнопки в файле catalog.swf, обслуживаемом по протоколу HTTP, для добавления элементов в корзину для покупок в файле cart.swf, обслуживаемом по протоколу HTTPS. Для этого в файле cart.swf вызывается метод allowInsecureDomain(), который позволяет файлу catalog.swf выполнять сценарий в файле cart.swf. Результат этого действия может быть непредвиденным: теперь злоумышленник может изменить файл catalog.swf при его первоначальной загрузке пользователем, поскольку файл catalog.swf передается по протоколу HTTP и не защищен от атак. Теперь злоумышленник, изменивший файл catalog.swf, может выполнять сценарий в файле script cart.swf, поскольку в файле cart.swf содержится вызов метода allowInsecureDomain(). В измененном файле catalog.swf можно использовать код ActionScript для доступа к переменным в файле cart.swf, что позволяет считывать пользовательскую информацию о кредитных картах и другие конфиденциальные данные. Затем измененный файл catalog.swf может передавать эти данные на сервер злоумышленника.

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

• Обслуживание всех SWF-файлов необходимо выполнять в приложении по протоколу HTTPS. Это явно наиболее простое и надежное решение. В описанном сценарии оба файла — catalog.swf и cart.swf — необходимо обслуживать по протоколу HTTPS. Слегка может увеличиться использование полосы пропускания и нагрузка на ЦП сервера при переключении в файле, например catalog.swf, протокола HTTP на протокол HTTPS, а на компьютерах пользователей может слегка увеличиться время загрузки приложений. Необходимо провести испытания на реальных серверах, чтобы определить степень важности этих эффектов; обычно увеличения происходят не более чем на 10-20%, а иногда они вовсе отсутствуют. Повысить эффективность можно с использованием на сервере оборудования или программ для ускорения при передаче по протоколу HTTPS. Основным преимуществом обслуживания всех взаимосвязанных SWF-файлов по протоколу HTTPS является то, что можно использовать указатель URL HTTPS в качестве основного URL-адреса в браузере без получения предупреждений о смешанном содержимом в браузере. Кроме того, в браузере становится видимым значок висячего замка, предоставляющего пользователям общие и доверенные индикаторы защиты.
• Используйте выполнение сценариев из HTTPS в HTTP вместо из HTTP в HTTPS. В описанном сценарии содержимое пользовательской корзины для покупок можно сохранить в файле catalog.swf, а в файле cart.swf только управлять процессом расчета. Во время расчета файл cart.swf может получать содержимое корзины из переменных ActionScript в файле catalog.swf. Ограничением выполнения сценариев из HTTP в HTTPS является асимметричность; несмотря на то, что в файле catalog.swf, доставленном по протоколу HTTP, нельзя безопасно разрешить выполнение сценария в файле cart.swf, доставленном по протоколу HTTPS, файл cart.swf HTTPS может выполнять сценарии в файле catalog.swf HTTP. Этот подход является не настолько простым, как подход, при котором все файлы передаются по протоколу HTTPS; необходимо проявлять осторожность и не доверять всем SWF-файлам, полученным по протоколу HTTP, поскольку они подвержены несанкционированному доступу. Например, когда файл cart.swf получает переменную ActionScript, в которой описано содержимое корзины, код ActionScript в файле cart.swf не может доверять данному значению переменной, даже если она получена в ожидаемом формате. Необходимо убедиться, что в содержимом корзины отсутствуют недопустимые данные, которые приведут к тому, что в файле cart.swf будет предпринято нежелательное действие. Необходимо также учитывать риск, что злоумышленник, изменив файл catalog.swf, может предоставить действительные, но неточные данные в файле cart.swf (например путем замены элементов в пользовательской корзине). Принятый процесс оформления покупок в некоторой степени позволяет устранить риск путем отображения содержимого тележки и общей стоимости покупок для окончательного одобрения пользователем, но риск все равно существует.

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

Дополнительные сведения о безопасности см. в разделе центра разработчиков Flash Player Безопасность.

Параметры

Связанные элементы API

Поиск файла политик в каталоге, заданном параметром url. Приложение Adobe AIR и проигрыватель Flash Player используют файлы политик, чтобы определить, можно ли разрешать приложениям загружать данные с других серверов, кроме того, на котором они находятся. Обратите внимание, что несмотря на то, что метод называется loadPolicyFile(), фактическая загрузка файла обычно не выполняется до получения сетевого запроса, который должен быть передан файлом политик.

С помощью метода Security.loadPolicyFile() проигрыватель Flash Player или приложение AIR может загружать файлы политик из произвольно выбранных местоположений, как это показано в следующем примере.

     Security.loadPolicyFile("http://www.example.com/sub/dir/pf.xml");
     

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

Например, в предыдущем коде не выдают исключение следующие строки:

 import flash.net.*;
     var request:URLRequest = new URLRequest("http://www.example.com/sub/dir/vars.txt");
     var loader:URLLoader = new URLLoader();
     loader.load(request);
     
     var loader2:URLLoader = new URLLoader();
     var request2:URLRequest = new URLRequest("http://www.example.com/sub/dir/deep/vars2.txt");
     loader2.load(request2);
     

Однако следующий код выдает исключение по безопасности:

 import flash.net.*;
     var request3:URLRequest = new URLRequest("http://www.example.com/elsewhere/vars3.txt");
     var loader3:URLLoader = new URLLoader();
     loader3.load(request3);
     

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

Проверяя основной файл политики, проигрыватель Flash Player ожидает ответа сервера в течение трех секунд. Если ответ не получен, Flash Player делает вывод, что основной файл политики не существует. Однако для вызова метода loadPolicyFile() нет тайм-аута по умолчанию; проигрыватель Flash Player предполагает, что вызываемый файл существует и ожидает загрузки в течение неопределенного времени. Поэтому для гарантированной загрузки основного файла политики необходимо вызвать метод loadPolicyFile().

Нельзя подключаться к общепринятым зарезервированным портам. Полный список заблокированных портов см. в разделе «Ограничение API-интерфейсов сетевого подключения» в руководстве ActionScript 3.0 Developer's Guide (руководстве разработчика по ActionScript 3.0).

Использование протокола xmlsocket вместе с определенным номером порта позволяет извлекать файл политики непосредственно с сервера XMLSocket, как показано в следующем примере. Описанное выше ограничение не распространяется на подключения через сокеты.

     Security.loadPolicyFile("xmlsocket://foo.com:414");
     

Это вызывает попытку проигрывателя Flash Player или приложения AIR получить файл политики из указанного хоста и порта. После того как соединение с указанным портом установлено, проигрыватель Flash Player или приложение AIR передает <policy-file-request />, прерываемый байтом со значением null. Сервер должен отправить байт null, чтобы прервать передачу файла политики, а после этого может закрыть соединение; если сервер не закроет соединение, это сделает проигрыватель Flash Player или приложение AIR после получения прерывающего байта null.

Можно запретить использование SWF-файлом этого метода путем установки параметра allowNetworking для тегов object и embed на странице HTML, содержащей SWF-содержимое.

Дополнительные сведения о безопасности см. в разделе центра разработчиков Flash Player Безопасность.

Параметры

Отображает панель параметров безопасности в проигрывателе Flash Player. Этот метод не применяется к содержимому в Adobe AIR; его вызов в приложении AIR игнорируется.

Параметры

Связанные элементы API

Файл работает в приложении AIR и был установлен с пакетом (файлом AIR) для этого приложения. Это содержимое включено в каталог ресурсов приложения AIR (в котором установлено содержимое приложения).

Связанные элементы API

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

Связанные элементы API

Файл является локальным файлом, не является доверенным для пользователя и не публиковался с сетевым наименованием. В Adobe AIR локальный файл не находится в каталоге ресурсов приложения. Такие файлы помещаются в изолированную программную среду безопасности приложения. Файл может считывать информацию из локальных источников данных, но не может обмениваться данными через Интернет.

Связанные элементы API

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

Связанные элементы API

Файл взят с URL-адреса в Интернете и работает в соответствии с правилами изолированной программной среды на основе домена.

Связанные элементы API