Что такое код swf_actiongeturl

Содержание

FPublisher

Web-технологии: База знаний

Документация PHP

swf_actiongeturl

swf_actiongeturl — Get a URL from a Shockwave Flash movie

Описание

void swf_actiongeturl ( string $url , string $target )

Gets the URL specified by the parameter url with the given target .

Список параметров

The URL, as a string.

The target, as a string.

Возвращаемые значения

Эта функция не возвращает значения после выполнения.

Последние поступления:

ТехЗадание на Землю

Размещена 14 марта 2020 года

Пpоект Genesis (из коpпоpативной пеpеписки)

Шпаргалка по работе с Vim

Размещена 05 декабря 2020 года

Vim довольно мощный редактор, но работа с ним не всегда наглядна.
Например если нужно отредактировать какой-то файл например при помощи crontab, без знания специфики работы с viv никак.

Ошибка: Error: Cannot find a val >Размещена 13 сентабря 2020 года

Если возникает ошибка на centos 5 вида
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
Eg. Invalid release/

Linux Optimization

Размещена 30 июля 2012 года

Способы вставки Flash в HTML и XHTML

«Как правильно вставить объекты Flash в вашу HTML-страницу?»

Это должно быть простой вопрос, но вероятно вызывает множество споров, так как каждый из доступных способов встраивания объектов имеет свои преимущества и недостатки. В этой статье мы исследуем трудности и тонкости встраивания Flash-содержимого и рассмотрим наиболее популярные способы вставки объектов.

Основные компоненты метода встраивания Flash-объектов

Прежде чем перейти к практике, давайте сначала охарактеризуем идеальный метод. По моему мнению, следующие критерии имеют первостепенное значение.

Соответствие стандартам

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

Межбраузерная поддержка

Поддержка всеми основными браузерами и популярными операционными системами — это необходимое условие. Проверить разметку можно с помощью инструментария Flash embed test suite, который позволяет оценить, поддерживают ли браузеры тот или иной метод разметки, с помощью которой можно вставить Flash-объекты. Этот набор тестов может показать информацию о параметрах, в том числе различных настройках Flash, потоках и сценариях, поддерживаемых браузерами и ОС. Вы также можете изучить сводную таблицу, отображающую эти параметры.

Поддержка альтернативного содержимого

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

Избежание несоответствия между Flash-контентом и версией Flash-плеера

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

Автоактивация интерактивного контента

Браузеры компании Microsoft работают так, что посетители не могут напрямую взаимодействовать с элементами управления Microsoft ActiveX, который позволяет загружать объекты и элементы embed , также называемые «интерактивным контентом».

Короче говоря, браузеры Microsoft не позволят взаимодействовать с интерактивным контентом, пока пользователь самостоятельно его не активирует. Opera также внедрила похожий механизм «click-to-activate». Этот механизм работает как «лежачий полицейский» на дороге: вы должны приостановить движение, медленно переехать через него, и только потом нажать педаль газа. Это может запутать обычного интернет-серфера и разозлить даже самого опытного.

Простота реализации

Конечно же простота имеет значение. Зачем прыгать выше головы, если можно сделать проще?

Основы встраивания Flash-объектов: embed и object

Существуют два элемента HTML, которые позволяют вставить объекты Flash на веб-страницу. В одной руке, у нас есть запатентованный элемент embed , который поддерживается большинством браузеров:

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

Большинство современных браузеров выбрали стандартом альтернативу тегу embed , используя при этом MIME-тип объекта, чтобы подключить соответствующий плагин для воспроизведения содержимого:

Этот метод не привязан к какому-либо определенному браузеру и поэтому это предпочтительная реализация.

Второй способ реализации создан специально для Internet Explorer на Windows. При этом требуется, чтобы вы определили атрибут classid у объекта, чтобы браузер смог загрузить необходимый элемент управления ActiveX Flash-плеера. Такой способ допустим, но зависим от типа браузера:

Замечание: В двух последних примерах кода специально не указан параметр codebase — он часто используется, чтобы уточнить URL инсталлятора Flash на серверах Adobe (браузер может автоматически загрузить его, если он еще не установлен). Однако это запрещено согласно спецификациям, которые ограничивают его доступ только в пределах домена текущего документа, и поэтому этот параметр не поддерживается всеми современными браузерами.

Почему embed все еще используется

С появлением веб-стандартов можно было бы совершенно обоснованно удалить элемент embed . Он просто никогда не был рекомендацией W3C и никогда не будет, потому что он уже запатентован. Однако в действительности этот способ лучше поддерживается браузерами, чем отдельная реализация элемента object . В результате такой способ реализации выбран на большинстве веб-сайтов, таких как Google Video и Brightcove.

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

Где нарушена поддержка веб-стандартов

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

  • Общая реализация объектов не работает в Internet Explorer на Windows. IE загружает плагин и SWF-файл, но не показывает его содержимое.
  • Когда мы частично объединяем два способа реализации добавлением параметра movie к общей реализации, Internet Explorer отображает Flash-контент, но не проигрывает его.
  • Если мы полностью соединим две реализации, все заработает в Internet Explorer, но браузеры на базе Gecko проигнорируют Flash-контент и покажут альтернативное содержимое.

Одной из особенностей элемента object является то, что вы можете вставлять этот тег друг в друга:

К сожалению, из-за ошибки в старых версиях Internet Explorer встроенные друг в друга элементы object рассматриваются так, как будто они следуют один за другим, поэтому отображаются оба элемента.

Еще хуже то, что браузеры Safari, начиная с версии 1.2.2 для Mac OS 10.3, игнорируют элемент param , встроенный в object , хотя поддерживают такие же атрибуты для элемента embed .

Замечание: Вы также можете спросить, насколько разумно определять контент, атрибуты и параметры дважды, как в вышеизложенном способе. Этот комбинированный метод также делает более проблематичным использование JavaScript для взаимодействия с Flash-контентом. В таком случае вы должны проверять, с каким объектом вы взаимодействуете.

Некоторые из ошибок уже исправлены, но необщепринятая и ошибочная в Internet Explorer реализация object все еще сдерживает абсолютное принятие этого элемента. Мы можем только надеяться, что это будет исправлено в ближайшем будущем.

Почему object лучше, чем embed

Несмотря на отсутствие поддержки всеми браузерами элемент object все же более предпочтителен, чем элемент embed , потому что кроме соответствия стандартам, он также обладает превосходной поддержкой альтернативного содержимого.

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

Элемент embed поддерживает альтернативное содержимое посредством элемента noembed , но такая реализация работает только в тех браузерах, которые не поддерживают сам элемент embed , например Internet Explorer на платформах Windows Mobile. В отличие от элемента object , embed не поддерживает альтернативное содержимое, когда поддерживается сам элемент embed , но не установлен Flash-плагин. В такой ситуации, можно довольствоваться только атрибутами pluginurl и pluginspage , с помощью которых отображается картинка, кликнув по которой можно установить плагин.

Я думаю, это лучшее решение для отображения альтернативного контента, чтобы описать необходимый плагин и дать намек на то, что пользователь может загрузить и установить плагин Flash. (Тем не менее, нет других причин, по которым мы должны злоупотреблять атрибутом codebase .)

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

Недостаточность методов разметки

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

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

Однако, давайте сделаем краткий обзор наиболее популярных «комбинированных» методов встранивания Flash, осуществляемых с помощью (X)HTML-разметки.

Двусоставный метод

В Flash IDE, вы можете создавать HTML-страницы с помощью так называемого двусоставного метода, объединяющего реализацию объектов с помощью элемента object и embed , встроенного внутри него как альтернативный контент:

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

Двусоставный метод использует избыточный код, делает ваши веб-страницы логически непоследовательными и не позволяет вставить альтернативное содержимое. А единственная преимущество — это простота в использовании, так как его генерирует Flash IDE: так что не пытайтесь просить воспроизвести этот метод по памяти.

Метод вложенных объектов

Вложение двух реализаций объектов — хорошая альтернатива двусоставному методу, потому что этот метод соответствует стандартам и поддерживает альтернативный контент:

К сожалению, в этом методе отсутствует межбраузерная поддержка вследствие ошибки вложения элементов object в IE и отсутствия поддержки вложенных элементов param в Safari. Но можно использовать прием с условными комментариями IE, чтобы избежать ошибок браузера:

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

Flash Satay

Другая альтернатива — это метод Flash Satay, который основан на общем способе реализации объектов и включает дополнительный параметр movie . Этот параметр необходим, чтобы избежать ошибок отображения контента в IE. Он также включает movie-контейнер Flash (c.swf с переменной path), чтобы исправить ошибку с потоковым воспроизведением в IE:

Хотя он приближает нас к «идеальному», универсальному способу реализации объектов, Flash Satay содержит приемы, применение которых не подойдет каждому? и при использовании этого метода встроенные элементы param не поддерживаются старыми версиями Safari.

Аргументы в пользу DOM

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

  • специальную реализацию для IE;
  • запатентованный элемент embed для старых версий Safari;
  • общую реализацию для всех остальных браузеров.

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

Решение с применением DOM также позволяет нам избежать механизма «click-to-activate» с помощью динамического создания элементов object .

Будьте осторожны, используя JavaScript

Так как не каждый является опытным специалистом по JavaScript — да и даже тот, кто им является, не должен заново изобретать велосипед — неплохо использовать уже существующие библиотеки JavaScript для встраивания Flash. Давайте рассмотрим критерии выбора надежной библиотеки.

Разметка по стандартам редко поддерживается создателями библиотек, так как эти библиотеки определяют Flash-контент либо в JavaScript, либо другими средствами разработки. Большинство библиотек создают неправильный HTML и, так как разметка написана динамически, W3C-валидатор не способен её проверить.

С другой стороны нужно рассмотреть, как работает такой метод, если JavaScript не доступен, не поддерживается или поддерживается только отчасти. Что делать, если используя JavaScript, вы ограничиваете доступность контента для пользователей?

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

Комплект по определению плейера Adobe Flash

Кроме создания разметки в Flash IDE, Adobe также предоставляет комплект по определению плейера Flash. Существует три способа использовать этот комплект:

  1. Проверив установлен или нет флажок Detect Flash Version (в меню File > Publish Settings > HTML) в Flash 8 IDE.
  2. Вставив его вручную, загрузив дистрибутив этой библиотеки.
  3. Работать в Flex Builder 2, где он включен по умолчанию.

Хотя пакет дает нам все желаемые возможности, такие как определение версии, экспресс-установка и автоактивация интерактивного контента, он нуждается в усовершенствовании. Когда мы полностью перейдем к стандартам, его ждет безнадежный провал: пока что он основан на двусоставной разметке, так как имеет либо реализацию объектов от Microsoft, либо поддержку запатентованного элемента embed , не соответствующего стандартам.

Он также поддерживает альтернативный контент, хотя странным и противоречивым образом. Вы должны определить альтернативный контент дважды: в JavaScript и в элементе noscript .

В конечном счете, комплект по определению плейера нуждается в лучшей реализации.

UFO и SWF Object

Популярные альтернативы с открытым исходным кодом, как UFO Боба ван дер Слуиса и SWF Object Джеффа Стирнса наверное самые полные и простые в использовании библиотеки, доступные в настоящее время.

Хотя на первый взгляд они кажутся похожими, они полностью отличаются внутренним содержанием. Например, SWF Object использует двусоставный метод Adobe, в то время как UFO генерирует главным образом соответствующую стандартам разметку. С другой стороны они используют общие архитектурные принципы: обе библиотеки построены на идее создания разметки, поддерживающей альтернативное содержимое (таким образом доступное и оптимизированное под поисковики), которое замещается DOM-скриптом, когда доступна необходимая поддержка Flash и JavaScript.

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

Аргументы в пользу «умеренного» программирования DOM

Чтобы решить все проблемы, вполне логично использовать следующий метод вставки: смешанную разметку, совместимую со стандартами, как та, которая используется методом Flash Satay, чтобы включить и Flash-контент, и альтернативное содержимое, наряду с применением небольшого DOM-скрипта, который необходим для устранения проблем в некоторых браузерах.

ObjectSwap основан на этих принципах и на мой взгляд является образцом для будущих библиотек встраивания Flash-объектов. К сожалению, ObjectSwap концентрируется в основном на автоактивации интерактивного контента, поэтому он не пригоден для определения версии и не решает проблем с разметкой, таких как поддержка потокового воспроизведения в IE или поддержка параметров в старых версиях Safari.

С другой стороны он может быть усовершенствован. При использовании события onload , поведение, основанное на DOM, реализуется только после загрузки всей страницы. Лучшим выбором могло бы быть событие DOMContentLoaded , которое позволяет вам применить свое собственное поведение, как только DOM станет доступен на странице. Так как событие DOMContentLoaded еще не полностью поддерживается браузерами, взамен этого вы можете использовать это решение.

Будущее встраивания Flash

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

Способы «защиты» flash-приложений

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

— введение

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

Борьба между системами защиты и системами обхода\снятия защит ведётся постоянно. Это связано с тем, что любому желающему доступна спецификация формата SWF и байткода (тут, здесь и ещё тут), в который компилируется ActionScript3 (далее AS3) код. Это позволяет свободно писать собственные библиотеки и приложения для разбора SWF файлов на составляющие (графику, звуки, байткод и т.д.), и делать что угодно с байткодом, например:

  • писать анализаторы байткода для декомпиляции ABC (ActionScript ByteСode) файлов, которые можно найти в тэгах «DoABC» в скомпилированном AS3 SWF файле (а в AS2 код обычно находится в тэгах «DoAction» и «DoInitAction»);
  • писать приложения, модифицирующие байткод, например, для его обфускации с помощью различных приёмов, которые могут использовать специфику декомпиляции в своих целях;
  • писать приложения, позволяющие изменять (патчить) байткод в уже скомпилированных SWF файлах;
  • модифицировать FP для вывода (трейса) исполняющегося байткода;

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

— содержание

— 1. URL-Lock, защита от локального запуска

Цель – заставить SWF файл работать в определенных условиях, например, только под одним или несколькими доменами, либо запретить локальный запуск.
После определения того факта, что SWF запущен не там, где должен бы, можно запрограммировать его поведение как угодно. Вы можете отправлять на сервер неугодные домены\URL (если это не localhost) и заносить в какой-нибудь лог.
Подлинные домены (под которыми должен работать SWF файл) лучше держать в зашифрованном виде или не держать в клиенте вообще (принимать от сервера также в зашифрованном виде).
Рассмотрим несколько способов привязки к доменам и определения локального запуска.

Привязка к доменам с помощью получения текущего URL\домена

Это самый распространённый способ привязки к домену. Для получения текущего URL или домена обычно используют:

а) loaderInfo:

  • root.loaderInfo.url ( _root._url – для AS2) – содержит путь до самого SWF файла, если SWF загружен с помощью другого SWF, то root.loaderInfo.url у загруженного SWF останется прежним
  • root.loaderInfo.loaderURL – содержит путь до самого SWF файла, либо до его загрузчика, если он был загружен с помощью другого SWF файла
  • root.loaderInfo.loader — содержит ссылку на экземпляр класса Loader, либо null, если SWF не был загружен внешним загрузчиком (заметьте, что root.loaderInfo.loader == root.parent , а root.parent == stage , если SWF не имеет загрузчика). Причём, если загрузчик не находится в доверенной зоне (находится в другом SecurityDomain), то при обращении к root.loaderInfo.loader или к root.parent из загружаемого SWF, будет возникать исключение SecurityError, в сообщении которого также будет содержаться ссылка до загрузчика

Пути не изменятся, если SWF встроить в HTML страницу на «неродном» домене без перемещения самого SWF файла.

б) LocalConnection: позволяет получить имя домена, под которым в данный момент запущен SWF файл с помощью LocalConnection.domain .
Если чужой SWF находится в домене, отличном от домена Вашего SWF, и Вы загрузили тот SWF в текущий домен безопасности так:
или с помощью Loader.loadBytes , то LocalConnection.domain загруженного SWF будет содержать домен Вашего SWF.
Пути не изменятся, если SWF встроить в HTML страницу на «неродном» домене без перемещения самого SWF файла.

в) ExternalInterface: позволяет использовать JavaScript (далее JS). Например, путь до текущей страницы, в которую встроен SWF, можно получить с помощью window.location.href . Для вызова JS используйте ExternalInterface.call . Т.к. call в качестве первого параметра принимает название метода, а window.location.href – свойство, то следует использовать toString():
Кстати, домен тоже можно получить через ExternalInterface.call :

ExternalInterface можно использовать и для вызова своих JS функций на той странице, где находится SWF – как изначально существующих, так и созданных Вами с помощью eval:
И не стоит забывать, что этот способ требует выполнения JS, что не всегда возможно.
При попытке обойти с помощью встраивания в HTML страницу на «неродном» домене без перемещения самого SWF файла, выполнение ExternalInterface.call будет генерировать SecurityError.

г) FlashVars: иногда, при размещении SWF в HTML страничке или при загрузке из другого SWF, передают путь до домена и\или иные данные через FlashVars (что на самом деле – плохо, т.к. это явная «дыра» для отвязки от доменов):

FlashVars можно передать в качестве параметра:
или через имя файла:

Дотянуться до FlashVars можно так:
— в AS3 – root.loaderInfo.parameters.var1
— в AS2 – _root.var1

Привязка к доменам без получения текущего URL или домена

Этот способ основан на кроссдоменной политике безопасности. Привязываемый SWF при запуске пытается загрузить по прямому пути «специальный» файл-пустышку с определённого хоста, на котором находится файл crossdomain.xml с разрешением загрузки ресурсов только с доверенных доменов, на одном из которых и должен находиться SWF. Соответственно, если «ворованный» SWF файл будет обращаться к «специальному» файлу с домена, не прописанного в crossdomain.xml, произойдет нарушение изолированной среды (sandbox security violation) и «специальный» файл не загрузится. Также при этом сгенерируется исключение и сработает событие SecurityErrorEvent.SECURITY_ERROR у экземпляра класса LoaderInfo ( Loader.contentLoaderInfo ). Это позволит определить то, что SWF находится не там, где должен бы.
К «специальному» файлу следует обращаться по прямому пути, чтобы предотвратить его подмену.

Илон Маск рекомендует:  Что такое код array_unique

Определение локального запуска

Локальный запуск SWF можно определить с помощью получения ссылки на SWF или HTML и проверки её на наличие подстроки «file://».
Если SWF запущен вне HTML, то метод ExternalInterface.call вернёт null.
Также можно проверить тип FP, в котором работает SWF, с помощью Capabilities.playerType :

  • «ActiveX» – при проигрывании через ActiveX FP, который, например, используется в IE
  • «Desktop» – для среды выполнения Adobe AIR (кроме SWF-содержимого, загруженного HTML страницей, со свойством Capabilities.playerType имеющим значение «PlugIn»)
  • «External» – при проигрывании через внешний FP или при запуске из-под Flash Professional IDE
  • «PlugIn» – при проигрывании через браузерный плагин (и для SWF-содержимого, загруженного HTML страницей в AIR приложении)
  • «StandAlone» – при проигрывании через автономный FP (при запуске локального SWF файла в браузерах, значение Capabilities.playerType != «StandAlone» )

Ещё один способ – с помощью сравнения Security.sandboxType с Security.REMOTE .

Все эти приёмы имеют свои преимущества и недостатки — некоторые не требуют сервера, но требуют перекомпиляции SWF файла при изменении доменов, к которым должна осуществляться привязка, а некоторые — наоборот.
В кодах к статье (ссылка на архив есть в конце статьи), в папке «1-URL Lock», вы найдёте пример с реализацией некоторых из описанных методов и пару примеров патчей одного из методов.
Внимание! Большинство приёмов URL-Lock можно обойти, работая из-под локального сервера, такого, как Denwer или XAMPP.

— 2. Переменные, ресурсы и классы

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

Защита переменных

Переменные надо прятать и защищать от изменений. Наиболее простой способ скрытия – написание своих «обёрток» вокруг базовых классов.
Например, CryptInt, CryptString и т.д. В самих классах можно написать методы для получения и отдачи значения, шифруя или расшифровывая его, что спрячет переменную в памяти. Взгляните на реализацию классов CryptInt и CryptString в кодах к статье, в папке «2-Memory&Domain\MemoryExample».
Также, для сокрытия значений переменных, можно разбивать их на составляющие, перемешивать, сдвигать и т.д. Можно даже попробовать написать некий конвейер, который будет перемещать скрываемое значение из одних переменных в другие, освобождая использованные переменные для GC (Garbage Collector). В качестве «временных хранилищ» для таких вот перерабатываемых переменных, можно использовать ByteArray, возможно, с привлечением «Алхимии» (fastmem из Azoth, Memory из Apparat).
А чтобы переменные не смогли поменять, даже если их найдут, то можно использовать, например, сравнение значения переменной с эталоном. Причём сравнение можно производить как при изменении переменной или обращении к ней, так и через заданные промежутки времени.

Подмена ресурсов

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

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

Переопределение классов

Скажу сразу, что гарантированно от этого защититься также не получится.
Подменять классы можно с помощью загрузки целевого SWF в ApplicationDomain загрузчика. Чтобы это сделать, можно написать загрузчик, содержащий класс с таким же именем, что и у подменяемого, и загрузить SWF в свой домен:
Таким образом, загружаемый SWF вынужден будет «общаться» с классом из своего загрузчика. Примеры реализации Вы сможете посмотреть в кодах к статье, в папке «2-Memory&Domain\applicationDomain». Вы встретите там примеры подмены классов с помощью загрузки в дочерний и в свой домен. В «жертве» Вы сможете найти несколько вариантов проверки на загруженность (которые обходятся заменой класса, в котором они содержатся).
Можно попытаться воспрепятствовать этому, загружая основной SWF через собственный загрузчик в новый ApplicationDomain:
и установив прочную связь между загрузчиком и основным SWF так, чтобы их было очень трудно «разлучить». Однако, если подменят загрузчик и сумеют эту связь сохранить, то эти усилия будут напрасны.

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

— 3. Водяные знаки (watermarks)

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

Вот некоторые их типы:

  1. Хорошо заметные элементы: текст, логотип, изображение и т.д.
    Если метка «впаяна» (относится как просто к изображениям, так и к графике в SWF), то её удаление придётся осуществлять вручную, редактируя данные, которые подверглись применению метки, что может оказаться очень сложной или вовсе невыполнимой задачей.
    Если же метка лежит отдельно (либо добавляется программно), например, на самом верхнем «слое» в SWF, то шансы аккуратно её удалить гораздо выше.
  2. Скрытые элементы. Они могут быть где угодно. От таких водяных знаков зачастую невозможно избавиться, т.к. никто кроме их создателей не будет знать, где искать. Такие метки должны быть уникальными, дабы была возможность доказать в суде, что это действительно метки, и что их невозможно повторить.

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

— 4. «Упаковывание» SWF

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

Вы можете добавить SWF в свой flex или flash проект с помощью тэга Embed, например, так:
Добавленный таким образом файл (это может быть любой двоичный файл или несколько файлов, если тэгов Embed будет несколько) помещается в тэг DefineBinaryData.
Далее можно загрузить «упакованный» таким образом файл с помощью Loader.loadBytes примерно так:
Существует масса инструментов для разбора SWF файлов и манипуляции с тэгами, благодаря которым существует возможность заменять или добавлять тэг DefineBinaryData.
Зная всё это, можно набросать свой простой «упаковщик» для автоматизации процесса. Перед оборачиванием, SWF можно как-нибудь преобразовать, например, обработав простым и быстрым симметричным xor’ом, а в загрузчике (который будет содержать «упакованный» SWF) написать код, который будет расшифровывать хранящийся в нём SWF, и уже затем его загружать. Простое «шифрование» с помощью xor нужно лишь для защиты от автоматической обработки декомпиляторами, чтобы SWF файл не находился внутри загрузчика в «чистом виде», более сложное шифрование бессмысленно.
Бывает, файлы «внедряют» и другими способами, например, в виде BitmapData, а также, создают несколько уровней вложенности.

Пример реализации простейшего упаковщика Вы сможете найти в кодах к статье, в папке «3-SWFPacker». Также там лежат два файла: orig.swf и packed.swf – можете попробовать их декомпилировать и сравнить.
Этот способ обходится, как минимум, двумя путями:
— исследование алгоритма расшифровщика в загрузчике и написание собственного расшифровщика (трудоёмко, особенно при большой вложенности загрузчиков)
— сохранение участка памяти, в котором находится уже распакованный и загруженный в FP SWF файл (просто и быстро, особенно, если не использованы средства защиты от сохранения из памяти, о которых написано ниже)

— 5. Динамическая генерация кода и редактирование SWF

Меня уже неоднократно спрашивали – возможно ли во flash в реальном времени генерировать код или создавать и редактировать другие SWF файлы? Ответ – да, это возможно!
Что касается кода, попробуйте AS3Commons ByteCode. Этот проект позволит Вам собирать и выполнять в реальном времени байткод.
Вы можете создавать классы с различными методами и свойствами с нуля, или наследуясь от других классов. Тела методов, например, могут описываются с помощью байткода линейно — methodBuilder.addOpcode(Opcode.getlocal_0) , или сразу блоками:
Вы можете загрузить сгенерированный код в AVM с помощью abcBuilder.buildAndLoad() .
Также для манипуляций с байткодом Вы можете попробовать as3abc, который, по словам автора, является частичным портом замечательного framework’а Apparat от небезызвестного Joa Ebert’а.
Если же Вы мечтаете о динамическом исполнении скрипта, а не байткода, то посмотрите на as3scriptinglib. Используя этот проект, Вы сможете в реальном времени компилировать и выполнять ActionScript 3/ECMAScript скрипты, включая JavaScript. Посмотреть на то, как это работает можно во flex демо-приложении. К сожалению, проект давно не обновляется.

Для экспериментов с самим SWF файлом и его структурой, попробуйте as3swf или swfassist.

Возможность генерации кода на лету, а также возможности редактирования и создания SWF в реальном времени, позволяют создавать различные сложные сценарии и приёмы для запутывания злоумышленника и скрытия Вашего кода. Вот, например первые 3 приёма, что пришли мне на ум:

  1. Генерировать и исполнять код\байткод на клиентской стороне по частям, приходящим от сервера, оставляя недоброжелателям в оригинальном SWF из всего кода, лишь то, что Вам не жалко им оставить (код свободных библиотек, кнопок и т.д.) + код расшифровщика и «строителя» уже финального кода.
  2. Собирать SWF по частям на клиентской стороне, аналогично трюку с кодом – можно собирать по тэгам, получая их от сервера, или, распаковывая поодиночке из зашифрованных данных, упакованных в загрузчике.
  3. Создавать самомодифицирующийся в процессе исполнения код, который, например, будет по определённым правилам или шаблонам генерировать одни и те же методы разными способами. Например, i++ можно реализовать как i+=1 (и это будет разный байткод, по крайней мере, он сейчас разный, в FP 10.1), также циклы могут быть реализованы по-разному, и т.д.
    Возможно, удастся так исхитриться, чтобы сгенерированный код изменял те методы, которые его сгенерировали. Например, чтобы в следующей итерации их выполнения сгенерировались уже другие классы и методы, тем самым значительно усложняя и запутывая код, чтобы, в случае его получения злоумышленником, последнему пришлось потратить как можно больше времени на разбор всей этой «каши».
    Предполагаю, что это довольно сложный (или даже невозможный во flash) трюк. Реально работающей реализации этой идеи на flash я пока не встречал. Если Вы встречали – то подскажите где посмотреть, буду рад изучить.

— 6. Запутывание кода (obfuscation) и скрытие данных

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

Переименование — это, пожалуй, единственный необратимый и 100% работающий способ хоть что-то спрятать во flash. Суть метода заключается в изменении у методов, свойств, пакетов и других элементов имён, которые сохраняются после компиляции, но не используются при выполнении кода. Автоматически восстановить оригинальные имена невозможно, придётся это делать вручную, догадываясь о них по смыслу во время исследования кода. После обфускации новые имена могут содержать недопустимые символы или зарезервированные слова, что не позволит с лёгкостью перекомпилировать и использовать код, полученный после декомпиляции.

Иногда при обфускации байткода расставляют «ловушки» для декомпиляторов, основанные на том, что декомпиляторы анализируют код комплексно, блоками, в отличие от FP, который исполняет его линейно, например:

  • Некорректный «мёртвый код» — создаётся искусственный условный переход, который всегда отрабатывает только одну ветку. Таким образом, во второй ветке мы имеем код, который никогда не выполнится, но будет обрабатываться декомпиляторами. И если там что-то непредсказуемое (а мы можем сделать там что угодно, т.к. FP до туда никогда не доберётся), то некоторые декомпиляторы могут повести себя необычно – например, аварийно завершиться.
  • Непредсказуемые байты в тех областях, которые игнорирует FP, но которые не всегда игнорируют и корректно обрабатывают декомпиляторы.

Кроме того, код можно просто «замусорить», увеличив его в объёмах и снизив его читабельность. Это может негативно сказаться на производительности.

Скрытие данных можно осуществлять разными способами, например:

  • Скрытие в SWF тэгах. Как я уже говорил, можно использовать flex-тэг Embed для встраивания любых файлов в SWF тэг DefineBinaryData, однако, можно создать и SWF тэг своего типа (FP такие тэги просто пропускает) с любыми данными, и затем извлекать их во время выполнения с помощью самораспарсивания.
    Пример есть в файлах к статье, в папке «4-CustomTag» — там находится проект на основе уже упомянутой библиотеки as3swf (изменён класс com.codeazur.as3swf.factories.SWFTagFactory и добавлен com.codeazur.as3swf.tags.TagCustom ). При запуске, SWF проверит — нет ли уже в нём нового тэга, и если есть — то выведет текст из него в текстовое поле, а если тэг не найдётся, то создаст сам в своей копии новый тэг со строкой, загрузит получившийся SWF в себя же с помощью Loader.loadBytes() и ещё предложит сохранить его в новый SWF файл.
  • Пользовательские мета данные. Для внедрения своих метаданных, сначала их необходимо объявить в коде (можно перед объявлением класса, метода, переменной):
    А затем добавить их названия в «Additional compiler arguments» таким образом: -keep-as3-metadata+=FocusMeta,Cool. После этого, Вы сможете обращаться к своим мета данным через XML, который можно получить с помощью describeType() :

Некоторые декомпиляторы и дизассемблеры позволяют с лёгкостью находить и исследовать пользовательские тэги и метаданные.

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

— 7. Защита от сохранения SWF файла из памяти

Гарантированно защититься от дампа из памяти нельзя. Однако, есть несложный приём, который может усложнить процесс – можно создать множество фальшивых SWF-заголовков (именно по ним обычно ищут SWF файлы в памяти), которые помогут оригинальному SWF затеряться среди них. Чтобы Ваш SWF файл не выделялся на фоне других, можно создать массу фальшивых заголовков с размерами = размерам Вашего SWF файла.
Чтобы заголовки были видны в памяти, достаточно записать их в ByteArray. Вот пример реализации этого способа, вытянутый из загрузчика одного из протекторов:
Как Вы могли догадаться, swfBytes – это массив байт с началом «шаблонного» заголовка и «настройками» для создания «фальшивых» заголовков, а в цикле длина у «шаблонных» заголовков заполняется случайным значением в заданном диапазоне.

— 8. Инструментарий исследователя flash

Основываясь на собственном опыте, я бы порекомендовал эти инструменты (цены указаны на конец 2010 года):

Декомпиляторы:

  • Action Script Viewer (ASV) – умно анализирует код, строит timeline, видит все тэги, очень многое умеет. Стоимость лицензии на одного пользователя – $80.
  • AS3 Sorcerer (от разработчика ASV) – декомпилирует только код, для анализа кода используется движок ASV, работает быстро и очень качественно. Если Вы приобретали ASV в 2010 году, то лицензию на AS3 Sorcerer Вам предоставят бесплатно. Стоимость лицензии с бесплатными обновлениями на 3 месяца — $22.
  • Sothink SWF Decompiler – можно пользоваться на незащищённых проектах, если под рукой не оказалось ASV. Стоимость лицензии — $79.99.

Дизассемблеры (для работы с байткодом):

  • ASV и Sothink умеют показывать байткод, но этого не всегда достаточно.
  • Nemo440 – «Advanced ActionScript 3/ABC2/Flex 2/Flex 3/Flex 4/AIR disassembler». Бесплатен.
  • Yogda – «AVM2 bytecode workbench» – позволяет ассемблировать, патчить байткод, есть встроенная документация по байткоду, иногда падает при анализе защищённых SWF, однако периодически обновляется и обрастает функционалом. Бесплатен.
  • RABCDAsm – «Robust ABC (ActionScript Bytecode) [Dis-]Assembler» – замечательный консольный ассемблер\дизассемблер байткода. Бесплатен (+доступен исходный код).

Протекторы\обфускаторы:

  • secureSWF — из всей массы продуктов этой категории, что мне удалось попробовать, он единственный сумел качественно позаботиться о целостности и работоспособности всех подопытных приложений и при этом качественно выполнить свою основную задачу. Конечно же, не бывает идеальных продуктов в этой области, но secureSWF даёт очень хороший контроль над всем процессом защиты и позволяет тонко настроить различные параметры. Например, Вы можете настроить переопределяющие правила для переименования, установить уровень «замусоривания» кода и т.д. В самой дорогой редакции, Вы получаете также возможность «упаковывать» SWF или привязать её к домену. К сожалению, цена на этот продукт весьма высока: стоимость Standard редакции составляет $199.
  • irrFuscator — может Вам приглянуться за его возможности по обфускации исходного кода перед компиляцией, однако, я считаю, что такой подход значительно хуже по своему качеству, чем байткод обфускация, т.к. не позволяет использовать запрещённые компилятором символы и различные трюки с байткодом. Этот продукт также умеет работать на уровне байткода, но проекты, которые я пробовал им «накрывать» довольно часто оставались неработоспособными. Стоимость Standard редакции составляет 79 евро.
  • OBFU – пожалуй, это самый дорогой обфускатор для flash, который мне доводилось видеть ( стоимость – 1500 евро ). Автор обфускатора — Николя Канасье, создатель haXe. Не ясно – поддерживает ли он AS3, т.к. примеры, выложенные на сайте проекта, написаны на as2 и датированы 2005 годом. К сожалению, попробовать его в действии мне пока не довелось, поэтому если вдруг Вы его когда-то пробовали, то не поленитесь, напишите отзыв о нём в комментариях.

Также прошу обратить внимание, что Amayeta SWF Encrypt, DComSoft SWF Protector, Mochi Encryption – это не то, чем Вам стоило бы «защищать» свои проекты (на данный момент), вы потратите Ваши деньги на бесполезную защиту.
Более того, Вы можете и самостоятельно реализовать простейшую обфускацию, как, например, это сделано в примере от makc3d.

Депротекторы\декрипторы и т.д.:

  • SWF Reader – проект одного польского умельца — многофункциональный редактор, позволяет работать со структурами, тэгами и т.д. Также имеет встроенные декрипторы\депротекторы для некоторых известных продуктов (в частности, распаковщики для doSWF, secureSWF). Cтоимость лицензии – 10 евро.
  • SWF Decrypt – поможет Вам избавиться от Amayeta SWF Encrypt и DComSoft SWF Protector (Mochi Encryption также в планах разработчика). Бесплатен.

Разное:

  • SWiX – отличная утилита для редактирования тэгов SWF файла в удобном XML представлении. Бесплатна.

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

— эпилог

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

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

Материалы для изучения и источники информации для этой статьи (беспорядочно):

  1. Презентация Claus Wahlers «Hacking SWF» с FITC Amsterdam 2010.
  2. Доклад Симонова Валентина (valyard) «Кто и как взламывает наши игры» с FlashGAMM 2010
  3. Статья Никиты Лещенко на английском о том, как по-простому защитить ресурсы и код, используя шифрование.
  4. Статья от romamik «Защита своими руками».
  5. Статья от Nautilus «Как защитить вашу игру от ребрендинга».
  6. Статья от puzzlesea «Robolander, 25 days later. Защита, борьба с китайцами».
  7. Статья от flashco «Обфускаторы: от бесплатного до €1500».
  8. Alexis’ SWF Reference — описание тэгов всех версий формата, описание заголовка SWF файла и многое другое.
  9. OWASP – в некотором роде вики по вопросам безопасности, относящихся к flash (ссылки на статьи, инструменты и т.д.).
  10. Очень впечатляющая статья о модели безопасности во flash от senocular под названием «Security Domains, Application Domains, and More in ActionScript 3.0».
  11. Статьи от Adobe о безопасности во flash.
  12. Официальная статья от Adobe о безопасности во FP 10 (White Paper).

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

Url Helper. Action Url Helper. Action Url Helper. Action Method

Definition

Overloads

Generates a string to a fully qualified URL to an action method.

Generates a fully qualified URL to an action method by using the specified action name.

Generates a fully qualified URL to an action method by using the specified action name and route values.

Generates a fully qualified URL to an action method by using the specified action name and controller name.

Generates a fully qualified URL to an action method for the specified action name and route values.

Generates a fully qualified URL to an action method by using the specified action name, controller name, and route values.

Generates a fully qualified URL to an action method by using the specified action name, controller name, and route values.

Generates a fully qualified URL to an action method by using the specified action name, controller name, route values, and protocol to use.

Generates a fully qualified URL for an action method by using the specified action name, controller name, route values, and protocol to use.

Generates a fully qualified URL for an action method by using the specified action name, controller name, route values, protocol to use and host name.

Action() Action() Action()

Generates a string to a fully qualified URL to an action method.

Returns

A string to a fully qualified URL to an action method.

Action(String) Action(String) Action(String)

Generates a fully qualified URL to an action method by using the specified action name.

Parameters

The name of the action method.

Returns

The fully qualified URL to an action method.

Action(String, Object) Action(String, Object) Action(String, Object)

Generates a fully qualified URL to an action method by using the specified action name and route values.

Parameters

The name of the action method.

An object that contains the parameters for a route. The parameters are retrieved through reflection by examining the properties of the object. The object is typically created by using object initializer syntax.

Returns

The fully qualified URL to an action method.

Action(String, String) Action(String, String) Action(String, String)

Generates a fully qualified URL to an action method by using the specified action name and controller name.

Parameters

The name of the action method.

The name of the controller.

Returns

The fully qualified URL to an action method.

Action(String, RouteValueDictionary) Action(String, RouteValueDictionary) Action(String, RouteValueDictionary)

Generates a fully qualified URL to an action method for the specified action name and route values.

Parameters

The name of the action method.

An object that contains the parameters for a route.

Returns

The fully qualified URL to an action method.

Action(String, String, Object) Action(String, String, Object) Action(String, String, Object)

Generates a fully qualified URL to an action method by using the specified action name, controller name, and route values.

Parameters

The name of the action method.

The name of the controller.

An object that contains the parameters for a route. The parameters are retrieved through reflection by examining the properties of the object. The object is typically created by using object initializer syntax.

Returns

The fully qualified URL to an action method.

Action(String, String, RouteValueDictionary) Action(String, String, RouteValueDictionary) Action(String, String, RouteValueDictionary)

Generates a fully qualified URL to an action method by using the specified action name, controller name, and route values.

Parameters

The name of the action method.

The name of the controller.

An object that contains the parameters for a route.

Returns

The fully qualified URL to an action method.

Action(String, String, Object, String) Action(String, String, Object, String) Action(String, String, Object, String)

Generates a fully qualified URL to an action method by using the specified action name, controller name, route values, and protocol to use.

Parameters

The name of the action method.

The name of the controller.

Илон Маск рекомендует:  border-top-style в CSS

An object that contains the parameters for a route. The parameters are retrieved through reflection by examining the properties of the object. The object is typically created by using object initializer syntax.

The protocol for the URL, such as «http» or «https».

Returns

The fully qualified URL to an action method.

Action(String, String, RouteValueDictionary, String) Action(String, String, RouteValueDictionary, String) Action(String, String, RouteValueDictionary, String)

Generates a fully qualified URL for an action method by using the specified action name, controller name, route values, and protocol to use.

Parameters

The name of the action method.

The name of the controller.

An object that contains the parameters for a route.

The protocol for the URL, such as «http» or «https».

Returns

The fully qualified URL to an action method.

Action(String, String, RouteValueDictionary, String, String) Action(String, String, RouteValueDictionary, String, String) Action(String, String, RouteValueDictionary, String, String)

Generates a fully qualified URL for an action method by using the specified action name, controller name, route values, protocol to use and host name.

Parameters

The name of the action method.

The name of the controller.

An object that contains the parameters for a route.

The protocol for the URL, such as «http» or «https».

The host name for the URL.

Returns

The fully qualified URL to an action method.

Подделка заголовков HTTP запроса с помощью Flash ActionScript

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

Flash Player – популярное дополнение к браузеру от компании Adobe (изначально флеш был разработан Macromedia, которую позже купил Adobe). В этой статье рассматриваются Flash 7-й и 8-й версии, которые установлены более чем на 94% рабочих станций, имеющих выход в Интернет (согласно опросу NPD Online Survey в апреле 2006 года). Flash анимация поставляется в виде файлов SWF (ShockWave File). Adobe также разработал язык ActionScript, напоминающий Javascript, который используется внутри Flash роликов. ActionScript позволяет посылать произвольные HTTP запросы к произвольным сайтам через Web браузер, проигрывающий флеш-ролик. В результате можно сформировать запрос к сайту, который нельзя выполнить через обычный Javascript код. Также в запросе можно задать произвольные HTTP заголовки в исходящем HTTP запросе.

Посылаем произвольный HTTP заголовок через Flash

Следующий синтаксис в ActionScript 2.0 позволяет послать GET запрос (в нашем примере на сайт http://www.vuln.site/some/page.cgi?p1=v1&p2=v2) с произвольным HTTP заголовком (Foo: Bar). Этот код работает с Flash 7 и 8 версии (возможно, работает и в 6-й версии):

var req:LoadVars=new LoadVars();
req.addRequestHeader(«Foo»,»Bar»);
req.send(«http://www.vuln.site/some/page.cgi?p1=v1&p2=v2»,
«_blank»,»GET»);

Похожий синтаксис используется для отправки POST запросов (с тем же самым заголовком, с телом запроса a=b&c=d):

var req:LoadVars=new LoadVars();
req.addRequestHeader(«Foo»,»Bar»);
req.decode(«a=b&c=d»);
req.send(«http://www.vuln.site/some/page.cgi?p1=v1&p2=v2»,
«_blank»,»POST»);

(Примечание: метод LoadVars.decode() был добавлен в Flash 7)

Запрос посылается из браузера, выполняющего Flash объект. Любые куки, которые обычно отправляет браузер, будут также посланы в этом случае. Посылается также User-Agent браузера и все стандартные заголовки браузера. Также поддерживаются HTTPS-запросы.
Эти примеры проверены и работают с Microsoft IE 6.0, Microsoft IE 6.0 SP2 и FireFox 1.5.0.4, с установленными Flash 8.0.22.0 и Flash 7.0.19.0 плагинами.

В IE также существует возможность переписать “нормальные” заголовки браузера, добавляя addRequestHeader с новым значением заголовка, в т.ч. заголовки Referrer и User-Agent. В FireFox 1.5.0.4, при использовании addRequestHeader(), заголовки будут добавлены к HTTP запросу.

// Один User-Agent в IE 6.0 SP2, 2 User-Agent в FF 1.5.0.4
req.addRequestHeader(«User-Agent»,»Hacker/1.0″);

// Один Referer в IE 6.0 SP2, два Referers в FF 1.5.0.4
req.addRequestHeader(«Referer»,»http://somewhere/»);

В IE, также можно переписать некоторые чувствительные заголовки, (например Host и Content-Length), добавляя двоеточие к имени заголовка:

Этот метод не работает в FireFox 1.5.0.4.

Влияние на безопасность

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

Важно понять, что этот тип нападения по сути не является обычной XSS атакой, так как не воздействует на межсайтовое доверие внутри Flash объекта, или на доверие между Flash объектом и внедренной HTML страницей. Нападение лишь основывается на возможности послать запросы из Flash объекта к произвольному URL с произвольными HTTP заголовками. Такая возможность сама по себе является проблемой, так как позволяет атакующему посылать ссылку (к HTML странице внедренной в FLASH объекте, или непосредственно к Flash объекту, расположенному на Web сайте атакующего), которая выполнит флеш объект в браузере жертвы. Этот Flash объект пошлет HTTP запрос (с HTTP заголовками по выбору атакующего) к целевому Web сайту, и это, в свою очередь, поставит под угрозу безопасность браузер жертвы.

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

Пример 1 — «Expect» заголовок

Ранее была обнаружена уязвимость в Apache 1.3.34, 2.0.57 и 2.2.1, позволяющая внедрить HTML данные (включая произвольный Javascript код) через Expect заголовок. Однако производитель посчитал, что уязвимость невозможно поэксплуатировать, потому что не существует способа заставить браузер послать измененный Expect заголовок к целевому Web сайту. Однако, используя Flash объект, атакующий может заставить браузер послать такой запрос, заставив жертву кликнуть на ссылку http://www.evil.site/attack.swf. Этот URL содержит FLASH объект, который запустит следующий ActionScript код:

var req:LoadVars=new LoadVars();
req.addRequestHeader(«Expect»,
«»);
req.send(«http://www.target.site/»,»_blank»,»GET»);

Этот ActionScript пошлет запрос из браузера жертвы к целевому Web сайту (www.target.site) с Expect заголовком, содержащим произвольный HTML (Javascript) код. Если целевой Web сайт работает на уязвимой версии Apache, то в результате будет возможно осуществить атаку межсайтового скриптинга. XSS атака возможна против Apache 1.3.34, 2.0.57 и 2.2.1, если браузер клиента IE или Firefox и поддерживает Flash 6/7+). В случае Apache 2.0/2.2, XSS ответ будет возвращен только после истечения времени ожидания (обычно несколько минут). Уязвимость устранена в последних версиях Apache – 1.3.35, 2.0.58 и 2.2.2 соответственно).

Пример 2 — CSRF и Referer

CSRF (Cross Site Request Forgery) атака позволяет атакующему заставить браузер жертвы выполнять различные действия (посылать HTTP запросы) на целевой сайт. Это редкий вид нападение, который всплывал несколько раз — впервые в списке рассылки Zope («Client Side Trojans»), и несколько раз в BugTraq под именем CSRF. Обе ссылки советуют, кроме других методов, доверять HTTP Refferer заголовку, как очевидность того, что браузер посылает этот заголовок от ссылки, которая расположена на Web сайте. Действительно, используя возможности HTML+Javascript, почти невозможно подменить Referer (единственный способ описан в http://www.securityfocus.com/archive/1/411585, однако он работает в ограниченном подмножестве сценариев, и не работает, если используется HTTPS). Однако, как было показано выше, можно обойти эти ограничения, используя Flash, в т.ч. и для изменения заголовка Referrer в HTTPS ресурсах, используя браузер, который посылает куки сайта вместе с запросом. В результате могут быть посланы GET запросы (с произвольным хостом и частью запроса) и POST запросы (с произвольным хостом, частью запроса и телом в стандартном Content-Type формате «application/x-www-form-urlencoded»).

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

Очевидно, что может быть подделан любой заголовок. В случае IE, заголовок, представленный браузером, может быть подменен атакующем (например, заголовок Referrer).

В случае браузера Firefox, заголовок Referrer подменить не получится, так как Firefox добавляет заголовок последним заголовком в HTTP запросе. Однако некоторые Web приложения могут использовать последние значения заголовка, и также могут быть уязвимыми к этому способу атаки.

В результате становится возможным эксплуатация любой рефлективной атаки межсайтового скриптинга, которая использует заголовки HTTP запроса (например Referrer, User-Agent, Expect, Host, Content-Type).

Flash 9

Ограничения методики

  • URL и часть тела запроса должны быть всегда URL-кодированы. Таким образом, невозможно вставить SP, HT, CR и LF ( и множество других символов) в URL и тело запроса.
  • Могут использоваться только GET и POST методы.
  • В IE может быть послан только один вариант каждого заголовка.
  • В целом нельзя полностью управлять параметрами заголовков, например атакующий может иметь проблемы пытаясь послать специальные символы внутри заголовков.

Частичное решение

Первое ограничение этой методики – невозможность послать CR и LF в теле запроса. Это означает, что методика не может использоваться для отправки POST запросов с «multipart/form-data» content-type форматом (этот формат использует сырые CR и LF чтобы отметить заголовки и границы). Другими словами, POST запрос, тело которого содержит поток «multipart/form-data», не может быть послан из Flash плеера. Авторы Web приложения, могут использовать HTML формы со свойством ENCTYPE установленным к «multipart/form-data», и предписывать, что POST запрос содержит тело multipart/form-data. Если используются эти механизмы, то невозможно осуществить нападения описанные выше.

Это решение конечно слишком навязчиво – должны быть изменены HTML страница и получаемый сценарий, чтобы использовать multipart/form-data. На многих средствах разработки Web приложений это просто реализовать, но на некоторых нет (например, ASP или Perl). Кроме того, в случаях описанных в примере 1, HTTP заголовок интерпретируется и используется Apache Web сервером, это решение не применимо.

Будущие направления

HTTP Request Splitting и HTTP Request Smuggling — в IE + Flash 7/8 возможно послать Content-Length заголовок с произвольным значением. Это позволяет выполнить HTTP Request Splitting нападение. Также внедряя Transfer-Encoding заголовок или второй Content-Length заголовок, можно осуществить нападение HTTP Request Smuggling. Необходимо произвести дополнительные исследования, чтобы разработать возможные методы эксплуатации этих атак.

Flash 9 – Хотя в Flash 9 наложены более строгие ограничения на создания заголовков через LoadVars.addRequestHeader(), возможности языка ActionScript 3.0 более богаты чем ActionScript 2.0. Например, возможно будет послать другие HTTP методы, не только GET или POST (например, WebDAV). Необходимо более тщательно изучить возможности Flash 9 и ActionScript 3.0, чтобы понять их потенциал в обработке HTTP запросов.

Заключение

Подписывайтесь на каналы «SecurityLab» в Telegram и Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.

Способы вставки Flash в HTML и XHTML

«Как правильно вставить объекты Flash в вашу HTML-страницу?»

Это должно быть простой вопрос, но вероятно вызывает множество споров, так как каждый из доступных способов встраивания объектов имеет свои преимущества и недостатки. В этой статье мы исследуем трудности и тонкости встраивания Flash-содержимого и рассмотрим наиболее популярные способы вставки объектов.

Основные компоненты метода встраивания Flash-объектов

Прежде чем перейти к практике, давайте сначала охарактеризуем идеальный метод. По моему мнению, следующие критерии имеют первостепенное значение.

Соответствие стандартам

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

Межбраузерная поддержка

Поддержка всеми основными браузерами и популярными операционными системами — это необходимое условие. Проверить разметку можно с помощью инструментария Flash embed test suite, который позволяет оценить, поддерживают ли браузеры тот или иной метод разметки, с помощью которой можно вставить Flash-объекты. Этот набор тестов может показать информацию о параметрах, в том числе различных настройках Flash, потоках и сценариях, поддерживаемых браузерами и ОС. Вы также можете изучить сводную таблицу, отображающую эти параметры.

Поддержка альтернативного содержимого

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

Избежание несоответствия между Flash-контентом и версией Flash-плеера

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

Автоактивация интерактивного контента

Браузеры компании Microsoft работают так, что посетители не могут напрямую взаимодействовать с элементами управления Microsoft ActiveX, который позволяет загружать объекты и элементы embed , также называемые «интерактивным контентом».

Короче говоря, браузеры Microsoft не позволят взаимодействовать с интерактивным контентом, пока пользователь самостоятельно его не активирует. Opera также внедрила похожий механизм «click-to-activate». Этот механизм работает как «лежачий полицейский» на дороге: вы должны приостановить движение, медленно переехать через него, и только потом нажать педаль газа. Это может запутать обычного интернет-серфера и разозлить даже самого опытного.

Простота реализации

Конечно же простота имеет значение. Зачем прыгать выше головы, если можно сделать проще?

Основы встраивания Flash-объектов: embed и object

Существуют два элемента HTML, которые позволяют вставить объекты Flash на веб-страницу. В одной руке, у нас есть запатентованный элемент embed , который поддерживается большинством браузеров:

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

Большинство современных браузеров выбрали стандартом альтернативу тегу embed , используя при этом MIME-тип объекта, чтобы подключить соответствующий плагин для воспроизведения содержимого:

Этот метод не привязан к какому-либо определенному браузеру и поэтому это предпочтительная реализация.

Второй способ реализации создан специально для Internet Explorer на Windows. При этом требуется, чтобы вы определили атрибут classid у объекта, чтобы браузер смог загрузить необходимый элемент управления ActiveX Flash-плеера. Такой способ допустим, но зависим от типа браузера:

Замечание: В двух последних примерах кода специально не указан параметр codebase — он часто используется, чтобы уточнить URL инсталлятора Flash на серверах Adobe (браузер может автоматически загрузить его, если он еще не установлен). Однако это запрещено согласно спецификациям, которые ограничивают его доступ только в пределах домена текущего документа, и поэтому этот параметр не поддерживается всеми современными браузерами.

Почему embed все еще используется

С появлением веб-стандартов можно было бы совершенно обоснованно удалить элемент embed . Он просто никогда не был рекомендацией W3C и никогда не будет, потому что он уже запатентован. Однако в действительности этот способ лучше поддерживается браузерами, чем отдельная реализация элемента object . В результате такой способ реализации выбран на большинстве веб-сайтов, таких как Google Video и Brightcove.

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

Где нарушена поддержка веб-стандартов

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

  • Общая реализация объектов не работает в Internet Explorer на Windows. IE загружает плагин и SWF-файл, но не показывает его содержимое.
  • Когда мы частично объединяем два способа реализации добавлением параметра movie к общей реализации, Internet Explorer отображает Flash-контент, но не проигрывает его.
  • Если мы полностью соединим две реализации, все заработает в Internet Explorer, но браузеры на базе Gecko проигнорируют Flash-контент и покажут альтернативное содержимое.

Одной из особенностей элемента object является то, что вы можете вставлять этот тег друг в друга:

К сожалению, из-за ошибки в старых версиях Internet Explorer встроенные друг в друга элементы object рассматриваются так, как будто они следуют один за другим, поэтому отображаются оба элемента.

Еще хуже то, что браузеры Safari, начиная с версии 1.2.2 для Mac OS 10.3, игнорируют элемент param , встроенный в object , хотя поддерживают такие же атрибуты для элемента embed .

Замечание: Вы также можете спросить, насколько разумно определять контент, атрибуты и параметры дважды, как в вышеизложенном способе. Этот комбинированный метод также делает более проблематичным использование JavaScript для взаимодействия с Flash-контентом. В таком случае вы должны проверять, с каким объектом вы взаимодействуете.

Некоторые из ошибок уже исправлены, но необщепринятая и ошибочная в Internet Explorer реализация object все еще сдерживает абсолютное принятие этого элемента. Мы можем только надеяться, что это будет исправлено в ближайшем будущем.

Почему object лучше, чем embed

Несмотря на отсутствие поддержки всеми браузерами элемент object все же более предпочтителен, чем элемент embed , потому что кроме соответствия стандартам, он также обладает превосходной поддержкой альтернативного содержимого.

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

Элемент embed поддерживает альтернативное содержимое посредством элемента noembed , но такая реализация работает только в тех браузерах, которые не поддерживают сам элемент embed , например Internet Explorer на платформах Windows Mobile. В отличие от элемента object , embed не поддерживает альтернативное содержимое, когда поддерживается сам элемент embed , но не установлен Flash-плагин. В такой ситуации, можно довольствоваться только атрибутами pluginurl и pluginspage , с помощью которых отображается картинка, кликнув по которой можно установить плагин.

Я думаю, это лучшее решение для отображения альтернативного контента, чтобы описать необходимый плагин и дать намек на то, что пользователь может загрузить и установить плагин Flash. (Тем не менее, нет других причин, по которым мы должны злоупотреблять атрибутом codebase .)

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

Недостаточность методов разметки

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

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

Однако, давайте сделаем краткий обзор наиболее популярных «комбинированных» методов встранивания Flash, осуществляемых с помощью (X)HTML-разметки.

Двусоставный метод

В Flash IDE, вы можете создавать HTML-страницы с помощью так называемого двусоставного метода, объединяющего реализацию объектов с помощью элемента object и embed , встроенного внутри него как альтернативный контент:

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

Двусоставный метод использует избыточный код, делает ваши веб-страницы логически непоследовательными и не позволяет вставить альтернативное содержимое. А единственная преимущество — это простота в использовании, так как его генерирует Flash IDE: так что не пытайтесь просить воспроизвести этот метод по памяти.

Метод вложенных объектов

Вложение двух реализаций объектов — хорошая альтернатива двусоставному методу, потому что этот метод соответствует стандартам и поддерживает альтернативный контент:

К сожалению, в этом методе отсутствует межбраузерная поддержка вследствие ошибки вложения элементов object в IE и отсутствия поддержки вложенных элементов param в Safari. Но можно использовать прием с условными комментариями IE, чтобы избежать ошибок браузера:

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

Flash Satay

Другая альтернатива — это метод Flash Satay, который основан на общем способе реализации объектов и включает дополнительный параметр movie . Этот параметр необходим, чтобы избежать ошибок отображения контента в IE. Он также включает movie-контейнер Flash (c.swf с переменной path), чтобы исправить ошибку с потоковым воспроизведением в IE:

Хотя он приближает нас к «идеальному», универсальному способу реализации объектов, Flash Satay содержит приемы, применение которых не подойдет каждому? и при использовании этого метода встроенные элементы param не поддерживаются старыми версиями Safari.

Аргументы в пользу DOM

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

  • специальную реализацию для IE;
  • запатентованный элемент embed для старых версий Safari;
  • общую реализацию для всех остальных браузеров.

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

Решение с применением DOM также позволяет нам избежать механизма «click-to-activate» с помощью динамического создания элементов object .

Будьте осторожны, используя JavaScript

Так как не каждый является опытным специалистом по JavaScript — да и даже тот, кто им является, не должен заново изобретать велосипед — неплохо использовать уже существующие библиотеки JavaScript для встраивания Flash. Давайте рассмотрим критерии выбора надежной библиотеки.

Разметка по стандартам редко поддерживается создателями библиотек, так как эти библиотеки определяют Flash-контент либо в JavaScript, либо другими средствами разработки. Большинство библиотек создают неправильный HTML и, так как разметка написана динамически, W3C-валидатор не способен её проверить.

С другой стороны нужно рассмотреть, как работает такой метод, если JavaScript не доступен, не поддерживается или поддерживается только отчасти. Что делать, если используя JavaScript, вы ограничиваете доступность контента для пользователей?

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

Комплект по определению плейера Adobe Flash

Кроме создания разметки в Flash IDE, Adobe также предоставляет комплект по определению плейера Flash. Существует три способа использовать этот комплект:

  1. Проверив установлен или нет флажок Detect Flash Version (в меню File > Publish Settings > HTML) в Flash 8 IDE.
  2. Вставив его вручную, загрузив дистрибутив этой библиотеки.
  3. Работать в Flex Builder 2, где он включен по умолчанию.

Хотя пакет дает нам все желаемые возможности, такие как определение версии, экспресс-установка и автоактивация интерактивного контента, он нуждается в усовершенствовании. Когда мы полностью перейдем к стандартам, его ждет безнадежный провал: пока что он основан на двусоставной разметке, так как имеет либо реализацию объектов от Microsoft, либо поддержку запатентованного элемента embed , не соответствующего стандартам.

Он также поддерживает альтернативный контент, хотя странным и противоречивым образом. Вы должны определить альтернативный контент дважды: в JavaScript и в элементе noscript .

В конечном счете, комплект по определению плейера нуждается в лучшей реализации.

UFO и SWF Object

Популярные альтернативы с открытым исходным кодом, как UFO Боба ван дер Слуиса и SWF Object Джеффа Стирнса наверное самые полные и простые в использовании библиотеки, доступные в настоящее время.

Хотя на первый взгляд они кажутся похожими, они полностью отличаются внутренним содержанием. Например, SWF Object использует двусоставный метод Adobe, в то время как UFO генерирует главным образом соответствующую стандартам разметку. С другой стороны они используют общие архитектурные принципы: обе библиотеки построены на идее создания разметки, поддерживающей альтернативное содержимое (таким образом доступное и оптимизированное под поисковики), которое замещается DOM-скриптом, когда доступна необходимая поддержка Flash и JavaScript.

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

Аргументы в пользу «умеренного» программирования DOM

Чтобы решить все проблемы, вполне логично использовать следующий метод вставки: смешанную разметку, совместимую со стандартами, как та, которая используется методом Flash Satay, чтобы включить и Flash-контент, и альтернативное содержимое, наряду с применением небольшого DOM-скрипта, который необходим для устранения проблем в некоторых браузерах.

ObjectSwap основан на этих принципах и на мой взгляд является образцом для будущих библиотек встраивания Flash-объектов. К сожалению, ObjectSwap концентрируется в основном на автоактивации интерактивного контента, поэтому он не пригоден для определения версии и не решает проблем с разметкой, таких как поддержка потокового воспроизведения в IE или поддержка параметров в старых версиях Safari.

С другой стороны он может быть усовершенствован. При использовании события onload , поведение, основанное на DOM, реализуется только после загрузки всей страницы. Лучшим выбором могло бы быть событие DOMContentLoaded , которое позволяет вам применить свое собственное поведение, как только DOM станет доступен на странице. Так как событие DOMContentLoaded еще не полностью поддерживается браузерами, взамен этого вы можете использовать это решение.

Будущее встраивания Flash

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

Что такое код swf_actiongeturl

Код HTML для вставки флеш мы можем создать сами.

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

Теперь ещё раз по порядку.

1) Копируем вот этот код:

2) Открывем окно создания темы и нажимаем на значок HTML .

Илон Маск рекомендует:  Термины Delphi

Это тот же значок, который вы нажимаете при вставке видео.

3) В открывшиеся окно вставляем скопированный код.

4) Заменяем слова « ссылка на файл » 2 раза на ссылку на флеш.

Моя флешка находится по адресу http://www.pineapple.ru/farb/bufa_boo.swf

Я его взяла из адресной строки браузера, но могут быть и ещё варианты.

5) Обращаю ваше внимание, что в коде HTML присутствуют цифры.

В данном коде это 450 и 300 . Их тоже можно заменить, для того, чтобы увеличить или уменьшить размеры флешки.

Внимание: Умножайте или делите на один коэффициент, а то нарушите пропорции.

6) Далее, нажимаем кнопку « Обновить «.

Получаем жёлтый прямоугольник. Вот это и есть наша флешка.

7) Если ничего больше вставить не нужно (текст или картинку), то нажимаем « Опубликовать «.

Примечание для пользователей браузера Мазила : Для изменения размеров изображения можно цифры в коде HTML не заменять. А просто после нажатия кнопки » Обновить «, когда появится жёлтый прямоугольник, кликнуть по нему и растянуть или сжать, потянув курсором мыши от центра или к центру жёлтого прямоугольника.

И ещё: Скопируйте себе этот код HTML в Word или » Блокнот » и сохраните, чтобы потом долго не искать.

Или можете скачать этот код, сохранённый с расширением txt ЗДЕСЬ.

Вот что получилось.

Для запуска флешки нажмите GO.

Получение URL-ссылки из внешнего swf файла в Action script 3

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

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

Вы можете получить доступ к URL-адресу, но только если URL-адрес хранится в переменной public в swf, который вы загружаете.

Вы можете использовать loaderinfo, чтобы получить то, что ищете. Вы даже можете вызвать публичные функции загруженного swf. См. Этот пример кода:

Что такое код swf_actiongeturl

Группа: Admin
Сообщений: 2009
Пользователь №: 133
Регистрация: 5-February 04

Сегодня мы поговорим о таком понятии, как защита ваших флеш — произведений от различных надругательств. Я постараюсь расписать различные методы защиты и, где возможно, методы её преодоления. Поехали…

Одним из простейших способов защиты вашего флэша является установка пароля в Publish Settings… (File-> Publish Settings… или Ctrl+Shift+F12). Щелкаем по вкладке Flash, ставим галочку в поле Protect from import, вводим в поле Password что-нибудь левое или совершенно конкретное и все…

Если вы уверены, что теперь никто не сможет импортировать ваш флеш, то вы глубоко заблуждаетесь… Почему? Сейчас расскажу… Вообще я разделяю несколько видов «запаролевания» флешей… Вид первый: остался еще от четвертого Flash, при попытке импорта файла swf с данной защитой выскакивает вот такое окно:

Бороться с этим окошком очень просто… Открываем .swf файл hex-редактором, например я использовал HexEdit (просто ничего другого не было:), ищем сочетание 00 06, выделяем, удаляем, сохраняем…

Именно УДАЛЯЕМ, а не заменяем код 00 06 на 00 00! Файл становиться меньше, и назойливое окошко больше не появляется. Немного практики, и все получиться. Вид второй: появился с Flash 5, при попытке импорта выскакивает окошко с полем для ввода пароля на импорт файла:

После 3-х попыток ввода пароля выскакивает все тоже надоедливое окошко… Да, дела… Кого-то это может повергнуть в уныние, но не вас! Открываем swf файл все тем же hex-редактором, а дальше технология следующая…

Находим и выделяем самую длинную последовательность символов, неважно какие это символы, главное чтобы они были в начале файла и последовательность была непрерывна, т.е. без символов «.». Дальше выделяем подряд все символы последовательности плюс все точки слева и справа, не трогая другие символы. Как видите, я выделил последовательность символов от буквы «f» до непонятного символа с кодом BF. УДАЛЯЕМ данную последовательность, сохраняем файл. Если все сделано правильно, то импорт пройдет без сучка. Прошу прощения, если какие-то флеши все-таки не получиться импортировать, данный способ избавления от защиты основан ТОЛЬКО на личных наблюдениях, но вроде работает…

Ну как вам? Думаете, что жизнь прожита зря? И ничего нельзя сделать? В принципе, вы правы…

Вид третий: появился с приходом Flash MX, визуально процесс импорта защищенных файлов выглядит точно так же, как и у предыдущего вида. В чем же отличие? В настройках!

Видите галочку в поле Compress movie? Вот из-за неё-то и все проблемы…

В такой каше уже и не понять, что удалять, что оставлять… Но не нужно расстраиваться, все течет, все меняется… Сейчас в Интернете существует великое множество программ для снятия защиты с swf файлов, в том числе с упакованных и неупакованных флешей, например программа UnlockSWF 2.04. Её можно найти вот по этому адресу: http://buraks.com/unlockswf/unlockswf20.zip. Данный продукт является полностью(!) бесплатным! По картинке видно, что все довольно просто: отмечаете необходимые значения для .swf и сохраняете. Все!

Вот такая ситуация, дорогой читатель… Думаете, что хуже быть уже не может? Может, и еще как!

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

Для примера рассмотрим «простейшую» защиту от импорта. В новом файле нарисуем картинку (как вы понимаете вместо картинки может быть и мультик, и игра, разницы нет). Теперь конвертируем картинку в Movie Clip (надеюсь вы еще не забыли как это делается?). Редактируем получившийся клип: перемещаем первый фрейм, содержащий изображение, во второй фрейм. В Actions второго фрейма пишем: stop ();. Переходим на основную сцену. Получается, что теперь ничего не видно! Но, если запустить флеш, картинка появиться. Теперь попробуйте импортировать этот флеш в новый. Ну, как? Что-нибудь появилось? И не появиться! Смысл всего, что я написал выше, в следующем: Flash импортирует только то, что «видно», т.е. только то, что находиться непосредственно на Scene1 во фреймах, причем у Movie Clip’ов берется только первый фрейм. Вот такая нехитрая операция позволит избежать импорта ваших файлов и использования ваших флеш-картинок…

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

Полегчало? Ну, это ненадолго…

Наверное, вы не раз задумывались над тем, что неплохо было бы не только получить картинки из чужого флеша, но и стянуть ActionScript? Да, неплохо… Ну и что же вам мешает? Программы нет? Не знаете какую выбрать? Понятно…

На сегодняшний день этой проблемой занимаются многие компании… Следует выделить такие программные продукты:

Sothink SWF Decompiler — один из лучших декомпиляторов на сегодняшний день.

Action Script Viever — как понятно из названия, виевер ActionScript’а.

Flasm — не то чтобы декомпилер, но достаточно похож на него…

Давайте рассмотрим подробней эти замечательные программы.

Sothink SWF Decompiler — замечательное средство для выдирания не только ActionScript’а но и звуков, символов, графики…короче, всего что только можно выдрать. С помощью данного декомпилера можно разложить флеш по косточкам, а затем собрать заново. Имейте только в виду, что собрать флеш воедино гораздо сложней, чем препарировать. Требуются навыки. Проще, когда вы имеете дело со своим флешем, тогда восстановить исходник можно где-то за пол часа (конечно, все зависит от размера). Кроме того, что декомпилер поддерживает FlashMX, он еще может декомпилить .exe файлы созданные из флеша. Вообщем всем программа хороша, только есть одно НО. Программа платная, а демо версия, рассчитанная на 30 дней, выдает только по два ресурса с каждого фрейма… И картинки этой проги у меня нет, только вот такое окощко постоянно выскакивает:

потому что кончился 30-дневный период, а переустанавливать систему лень. Кряков тоже нет… Если кто найдет или знает где, пишите mitemail@mail.ru, расскажу всем …

Следующая прога Action Script Viever, тоже платная, позволяет выдирать ActionScript и не только… Вообщем, похожа на предыдущий декомпилер. Демку всегда можно взять здесь: http://www.buraks.com/asv/index.html. Но интересна не эта прога, как таковая, а БЕСПЛАТНЫЕ утилиты для флеша. Среди них, кстати, UnlockSWF и некоторые другие… Весь список доступен тут: http://buraks.com/swifty/. Кстати, на сайте-производителе есть еще одна прикольная прожка URL Action Editor, позволяющая изменять getURL, LoadMovie, UnloadMovie,LoadVariables и еще кое-что в swf.

Да, жизнь сегодня дорожает… Но есть все-таки на свете добрые люди. Программа Flasm является freeware и скачать ее можно без проблем с http://www.nowrap.de/flasm14.zip, причем в архиве находиться и документация (правда, на английском:), где все расписано, что и как делать… Кстати, если вы разбираетесь в С, то можете скачать также исходник. Работать с данной программой достаточно интересно.

Как видите, программа работает под ДОС, но это ничуть не умаляет её возможностей. Кстати Flasm полностью поддерживает FlashMX (кстати, можно распаковывать или сжимать swf)! Для того чтобы получить код какого-либо swf файла (заметьте, код, а не исходник!), достаточно написать:

где movie1.swf — некоторый файл, котрый мы хотим изменить. В той же папке, где и flasm появится еще один файл — movie1.flm, содержащий код флеша. Изменяем код, и компилируем .swf файл следующей командой:

flasm.exe -a movie1.flm

получаем новый movie1.swf с исправленным кодом! Правда, есть один нюанс — придется прочитать документацию на английском, чтобы знать, как редактировать flasm-код (своеобразный, знаете ли, код). Но разве это остановит настоящих исследователей.

Flasm — очень мощный инструмент в умелых руках, так что дерзайте!

Можете попытаться защитить свой флеш…а смысл? Все новые технологии постепенно становятся достоянием всего Интернет-сообщества…

Ну, что, дорогие флеш-мэйкеры? Еще не пропало желание писать flash? И даже не пугает, что сломать swf, с его открытой структурой, дело времени (кстати, здесь просматривается определенная аналогия между программированием на Flash и программированием под *nix — сломать даже проще, чем написать)? Ну, тогда пишите… Пишите флеши, хорошие и разные, а чтобы люди не мучались, положите где-нибудь рядом исходник…А если не положите… Всегда выйдет новая версия SWF Decompiler’а!

Способы вставки Flash в HTML и XHTML

«Как правильно вставить объекты Flash в вашу HTML-страницу?»

Это должно быть простой вопрос, но вероятно вызывает множество споров, так как каждый из доступных способов встраивания объектов имеет свои преимущества и недостатки. В этой статье мы исследуем трудности и тонкости встраивания Flash-содержимого и рассмотрим наиболее популярные способы вставки объектов.

Основные компоненты метода встраивания Flash-объектов

Прежде чем перейти к практике, давайте сначала охарактеризуем идеальный метод. По моему мнению, следующие критерии имеют первостепенное значение.

Соответствие стандартам

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

Межбраузерная поддержка

Поддержка всеми основными браузерами и популярными операционными системами — это необходимое условие. Проверить разметку можно с помощью инструментария Flash embed test suite, который позволяет оценить, поддерживают ли браузеры тот или иной метод разметки, с помощью которой можно вставить Flash-объекты. Этот набор тестов может показать информацию о параметрах, в том числе различных настройках Flash, потоках и сценариях, поддерживаемых браузерами и ОС. Вы также можете изучить сводную таблицу, отображающую эти параметры.

Поддержка альтернативного содержимого

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

Избежание несоответствия между Flash-контентом и версией Flash-плеера

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

Автоактивация интерактивного контента

Браузеры компании Microsoft работают так, что посетители не могут напрямую взаимодействовать с элементами управления Microsoft ActiveX, который позволяет загружать объекты и элементы embed , также называемые «интерактивным контентом».

Короче говоря, браузеры Microsoft не позволят взаимодействовать с интерактивным контентом, пока пользователь самостоятельно его не активирует. Opera также внедрила похожий механизм «click-to-activate». Этот механизм работает как «лежачий полицейский» на дороге: вы должны приостановить движение, медленно переехать через него, и только потом нажать педаль газа. Это может запутать обычного интернет-серфера и разозлить даже самого опытного.

Простота реализации

Конечно же простота имеет значение. Зачем прыгать выше головы, если можно сделать проще?

Основы встраивания Flash-объектов: embed и object

Существуют два элемента HTML, которые позволяют вставить объекты Flash на веб-страницу. В одной руке, у нас есть запатентованный элемент embed , который поддерживается большинством браузеров:

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

Большинство современных браузеров выбрали стандартом альтернативу тегу embed , используя при этом MIME-тип объекта, чтобы подключить соответствующий плагин для воспроизведения содержимого:

Этот метод не привязан к какому-либо определенному браузеру и поэтому это предпочтительная реализация.

Второй способ реализации создан специально для Internet Explorer на Windows. При этом требуется, чтобы вы определили атрибут classid у объекта, чтобы браузер смог загрузить необходимый элемент управления ActiveX Flash-плеера. Такой способ допустим, но зависим от типа браузера:

Замечание: В двух последних примерах кода специально не указан параметр codebase — он часто используется, чтобы уточнить URL инсталлятора Flash на серверах Adobe (браузер может автоматически загрузить его, если он еще не установлен). Однако это запрещено согласно спецификациям, которые ограничивают его доступ только в пределах домена текущего документа, и поэтому этот параметр не поддерживается всеми современными браузерами.

Почему embed все еще используется

С появлением веб-стандартов можно было бы совершенно обоснованно удалить элемент embed . Он просто никогда не был рекомендацией W3C и никогда не будет, потому что он уже запатентован. Однако в действительности этот способ лучше поддерживается браузерами, чем отдельная реализация элемента object . В результате такой способ реализации выбран на большинстве веб-сайтов, таких как Google Video и Brightcove.

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

Где нарушена поддержка веб-стандартов

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

  • Общая реализация объектов не работает в Internet Explorer на Windows. IE загружает плагин и SWF-файл, но не показывает его содержимое.
  • Когда мы частично объединяем два способа реализации добавлением параметра movie к общей реализации, Internet Explorer отображает Flash-контент, но не проигрывает его.
  • Если мы полностью соединим две реализации, все заработает в Internet Explorer, но браузеры на базе Gecko проигнорируют Flash-контент и покажут альтернативное содержимое.

Одной из особенностей элемента object является то, что вы можете вставлять этот тег друг в друга:

К сожалению, из-за ошибки в старых версиях Internet Explorer встроенные друг в друга элементы object рассматриваются так, как будто они следуют один за другим, поэтому отображаются оба элемента.

Еще хуже то, что браузеры Safari, начиная с версии 1.2.2 для Mac OS 10.3, игнорируют элемент param , встроенный в object , хотя поддерживают такие же атрибуты для элемента embed .

Замечание: Вы также можете спросить, насколько разумно определять контент, атрибуты и параметры дважды, как в вышеизложенном способе. Этот комбинированный метод также делает более проблематичным использование JavaScript для взаимодействия с Flash-контентом. В таком случае вы должны проверять, с каким объектом вы взаимодействуете.

Некоторые из ошибок уже исправлены, но необщепринятая и ошибочная в Internet Explorer реализация object все еще сдерживает абсолютное принятие этого элемента. Мы можем только надеяться, что это будет исправлено в ближайшем будущем.

Почему object лучше, чем embed

Несмотря на отсутствие поддержки всеми браузерами элемент object все же более предпочтителен, чем элемент embed , потому что кроме соответствия стандартам, он также обладает превосходной поддержкой альтернативного содержимого.

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

Элемент embed поддерживает альтернативное содержимое посредством элемента noembed , но такая реализация работает только в тех браузерах, которые не поддерживают сам элемент embed , например Internet Explorer на платформах Windows Mobile. В отличие от элемента object , embed не поддерживает альтернативное содержимое, когда поддерживается сам элемент embed , но не установлен Flash-плагин. В такой ситуации, можно довольствоваться только атрибутами pluginurl и pluginspage , с помощью которых отображается картинка, кликнув по которой можно установить плагин.

Я думаю, это лучшее решение для отображения альтернативного контента, чтобы описать необходимый плагин и дать намек на то, что пользователь может загрузить и установить плагин Flash. (Тем не менее, нет других причин, по которым мы должны злоупотреблять атрибутом codebase .)

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

Недостаточность методов разметки

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

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

Однако, давайте сделаем краткий обзор наиболее популярных «комбинированных» методов встранивания Flash, осуществляемых с помощью (X)HTML-разметки.

Двусоставный метод

В Flash IDE, вы можете создавать HTML-страницы с помощью так называемого двусоставного метода, объединяющего реализацию объектов с помощью элемента object и embed , встроенного внутри него как альтернативный контент:

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

Двусоставный метод использует избыточный код, делает ваши веб-страницы логически непоследовательными и не позволяет вставить альтернативное содержимое. А единственная преимущество — это простота в использовании, так как его генерирует Flash IDE: так что не пытайтесь просить воспроизвести этот метод по памяти.

Метод вложенных объектов

Вложение двух реализаций объектов — хорошая альтернатива двусоставному методу, потому что этот метод соответствует стандартам и поддерживает альтернативный контент:

К сожалению, в этом методе отсутствует межбраузерная поддержка вследствие ошибки вложения элементов object в IE и отсутствия поддержки вложенных элементов param в Safari. Но можно использовать прием с условными комментариями IE, чтобы избежать ошибок браузера:

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

Flash Satay

Другая альтернатива — это метод Flash Satay, который основан на общем способе реализации объектов и включает дополнительный параметр movie . Этот параметр необходим, чтобы избежать ошибок отображения контента в IE. Он также включает movie-контейнер Flash (c.swf с переменной path), чтобы исправить ошибку с потоковым воспроизведением в IE:

Хотя он приближает нас к «идеальному», универсальному способу реализации объектов, Flash Satay содержит приемы, применение которых не подойдет каждому? и при использовании этого метода встроенные элементы param не поддерживаются старыми версиями Safari.

Аргументы в пользу DOM

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

  • специальную реализацию для IE;
  • запатентованный элемент embed для старых версий Safari;
  • общую реализацию для всех остальных браузеров.

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

Решение с применением DOM также позволяет нам избежать механизма «click-to-activate» с помощью динамического создания элементов object .

Будьте осторожны, используя JavaScript

Так как не каждый является опытным специалистом по JavaScript — да и даже тот, кто им является, не должен заново изобретать велосипед — неплохо использовать уже существующие библиотеки JavaScript для встраивания Flash. Давайте рассмотрим критерии выбора надежной библиотеки.

Разметка по стандартам редко поддерживается создателями библиотек, так как эти библиотеки определяют Flash-контент либо в JavaScript, либо другими средствами разработки. Большинство библиотек создают неправильный HTML и, так как разметка написана динамически, W3C-валидатор не способен её проверить.

С другой стороны нужно рассмотреть, как работает такой метод, если JavaScript не доступен, не поддерживается или поддерживается только отчасти. Что делать, если используя JavaScript, вы ограничиваете доступность контента для пользователей?

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

Комплект по определению плейера Adobe Flash

Кроме создания разметки в Flash IDE, Adobe также предоставляет комплект по определению плейера Flash. Существует три способа использовать этот комплект:

  1. Проверив установлен или нет флажок Detect Flash Version (в меню File > Publish Settings > HTML) в Flash 8 IDE.
  2. Вставив его вручную, загрузив дистрибутив этой библиотеки.
  3. Работать в Flex Builder 2, где он включен по умолчанию.

Хотя пакет дает нам все желаемые возможности, такие как определение версии, экспресс-установка и автоактивация интерактивного контента, он нуждается в усовершенствовании. Когда мы полностью перейдем к стандартам, его ждет безнадежный провал: пока что он основан на двусоставной разметке, так как имеет либо реализацию объектов от Microsoft, либо поддержку запатентованного элемента embed , не соответствующего стандартам.

Он также поддерживает альтернативный контент, хотя странным и противоречивым образом. Вы должны определить альтернативный контент дважды: в JavaScript и в элементе noscript .

В конечном счете, комплект по определению плейера нуждается в лучшей реализации.

UFO и SWF Object

Популярные альтернативы с открытым исходным кодом, как UFO Боба ван дер Слуиса и SWF Object Джеффа Стирнса наверное самые полные и простые в использовании библиотеки, доступные в настоящее время.

Хотя на первый взгляд они кажутся похожими, они полностью отличаются внутренним содержанием. Например, SWF Object использует двусоставный метод Adobe, в то время как UFO генерирует главным образом соответствующую стандартам разметку. С другой стороны они используют общие архитектурные принципы: обе библиотеки построены на идее создания разметки, поддерживающей альтернативное содержимое (таким образом доступное и оптимизированное под поисковики), которое замещается DOM-скриптом, когда доступна необходимая поддержка Flash и JavaScript.

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

Аргументы в пользу «умеренного» программирования DOM

Чтобы решить все проблемы, вполне логично использовать следующий метод вставки: смешанную разметку, совместимую со стандартами, как та, которая используется методом Flash Satay, чтобы включить и Flash-контент, и альтернативное содержимое, наряду с применением небольшого DOM-скрипта, который необходим для устранения проблем в некоторых браузерах.

ObjectSwap основан на этих принципах и на мой взгляд является образцом для будущих библиотек встраивания Flash-объектов. К сожалению, ObjectSwap концентрируется в основном на автоактивации интерактивного контента, поэтому он не пригоден для определения версии и не решает проблем с разметкой, таких как поддержка потокового воспроизведения в IE или поддержка параметров в старых версиях Safari.

С другой стороны он может быть усовершенствован. При использовании события onload , поведение, основанное на DOM, реализуется только после загрузки всей страницы. Лучшим выбором могло бы быть событие DOMContentLoaded , которое позволяет вам применить свое собственное поведение, как только DOM станет доступен на странице. Так как событие DOMContentLoaded еще не полностью поддерживается браузерами, взамен этого вы можете использовать это решение.

Будущее встраивания Flash

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

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL