Как мне делать сеансы с Flash-клиентом?

Question

Поскольку Flash Player (или, точнее, класс URLLoader ) не позволит вам читать заголовки HTTP-ответов или куки-файлы, установленные сервером, и если вы получите куки-файл сеанса через некоторые обходные пути, например , обращающиеся к браузеру и запускающие JS , не могут быть отправлены на сервер, потому что, среди других , заголовок Cookie будет заблокирован.

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

1. включить маркер сеанса в полезную нагрузку HTTP
2. включить токен в URL
3. построить мой собственный HTTP-клиент (... с блэкджеком и перехватчиками ...) в AS, используя Socket класс

Мне не нравится (1), потому что я переопределяю функциональность в моем протоколе, который уже встроен в Struts, который я использую для реализации серверной части. Затем я должен убедиться, что либо оба ведут себя одинаково, либо отключить обычный способ управления сеансами, и заставить других клиентов использовать мой протокол, чтобы браузер мог с ним справиться.

Мне не нравится (2), потому что я понимаю, что с этим связаны проблемы безопасности, хотя Я не слишком уверен, какие

Мне не нравится (3), потому что сейчас 2010 год, и тонны HTTP-клиентов написаны умнее людей, чем я.

Итак, есть ли другие возможности? Какие из моих "не нравится" ты считаешь наименее серьезным? Есть ли способы смягчить проблемы, которые я перечислил? Например, насколько небезопасными являются токены сеансов в URL-адресах?

Answer 1

Как насчет использования параметра FlashVars? Он разработан специально для передачи простых данных в приложение Flash, и тривиально вставлять маркер сеанса в тег при создании страницы на стороне сервера. С точки зрения PHP, это будет что-то вроде

<embed href="movie.swf" flashvars="sessionID=<?= session_id(); ?>">blah blah blah</embed>

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

Более подробная информация здесь в документации Adobe.

Answer 2

Некоторые из ваших постов могли ускользнуть от меня, но знаете ли вы о общих объектах :

"Класс SharedObject используется для чтения и хранения ограниченных объемов данных на компьютере пользователя или на сервере. Общие объекты предлагают обмен данными в режиме реального времени между несколькими клиентскими SWF-файлами и объектами, которые сохраняются на локальном компьютере или на удаленном компьютере. сервер. Локальные общие объекты аналогичны файлам cookie браузера, а удаленные общие объекты аналогичны устройствам передачи данных в режиме реального времени.