Вы думаете: "Я уже знаю о переменных J2EE сессий"? Но речь пойдет не о них, а о трех новых возможностях, две из которых не зависят от J2EE спецификации и пока еще не знакомы CF разработчикам. А одна из них, для получения ощутимой выгоды, даже не требует каких-либо изменений в вашем коде. Эти возможности можно назвать так:
Управление переменными Session и Client без Cookies
Первая возможность - спрятанное сокровище, которое никто еще не нашел. Чтобы понять ее значимость, следует разобраться в некоторых основных понятиях. Если вам доводилось использовать переменные сессии (или клиентские переменные), то вы знаете, что их работа напрямую зависит от того, поддерживает ли броузер cookies, чтобы отслеживать количество пользователей (используя значения переменных CFID и CFTOKEN, сгенерированные CF сервером для каждого пользователя).
Проблема возникает тогда, когда при посещении вашего сайта в броузере пользователя cookie не поддерживаются (или не разрешены к использованию). В таком случае вы должны вручную добавлять переменные CFID и CFTOKEN к URL, используемому в таких HTML конструкциях как <a href=""> и <form action=""> (тег <cflocation> для этой же цели содержит параметр addtoken="yes").Вот что может произойти, если броузер пользователя не распознает cookies:
Таким образом, решением этой проблемы (в версиях до CFMX) может быть только определение присутствия поддержки cookies и если таковой нет, то только тогда следует добавлять значения CFID и CFTOKEN. Написать такой код не трудно, но неприятно то, что придется добавлять значения CFID и CFTOKEN во все конструкции <a href="">, <form action=""> и в теге <cflocation> (используя параметр addtoken="yes").
Новая функция URLSessionFormat()
С помощью этой простой функции вы теперь можете переложить на CFMX всю заботу о добавлении к URL значений CFID и CFTOKEN (и/или значение переменной JSessionID при использовании J2EE сессий, о чем пойдет речь ниже). Вот простой пример:
Если CFMX обнаруживает, что браузер во время обработки этого шаблона не передает необходимые cookie (CFID и CFTOKEN для CF сессии и клиентских переменных, JSessionID для переменных J2EE сессии), то будет сгенерирован такой HTML код: С другой стороны, если CFMX обнаружит, что все необходимые идентификаторы сессии были получены, то к адресной строке они добавлены не будут. Очень круто! Заметьте, что если адресная строка содержит строку запроса (как в приведенном примере), то идентификатор сессии будет добавлен с помощью амперсанда (&). Та-да! (В этом примере я пока еще не показываю, как это будет выглядеть с использованием J2EE сессий).Если вам нужно использовать функцию URLEncodedFormat для некоторого участка запроса, где есть пробелы и спец. символы, то можно использовать обе эти функции в одной строке. Пример выглядит громоздко, но он работает:
Одно замечание: я заметил, что при использовании J2EE сессий один из вариантов адресной строки может выглядеть так: MyPage.cfm;JSESSIONID=8030949691025145133137?name=bob. Заметьте, что в этом случае переменная JSESSIONID прикреплена к названию файла с помощью точки с запятой, а не так, как к строке запроса. Но, все-таки, если такое случилось, то ссылка продолжает работать как положено.Возможно вы обратили внимание, что название этой функции не совсем правильное. Это нужно для управления не только переменными сессий, но и клиентскими переменными. Другими словами, если вы используете клиентские переменные, а не переменными сессии, то эта функция будет гарантировать, что переменные CFID и CFTOKEN, также необходимые и для поддержки клиентских переменных, будут отправлены браузеру, не поддерживающему cookie.(Безусловно, если клиентские переменные используются наряду с J2EE сессией как показано в примере использования JSESSIONID, то переменные CFID и CFTOKEN также будут добавлены к строке запроса.).
Не стоит упускать тот факт, что есть браузеры, которые не используют cookie не потому что не поддерживают их, а потому, что во многих организациях заставляют сотрудников отключать поддержку cookie. Эта функция поможет вам поддерживать и такие браузеры.Использование UUID для CFTOKEN
Как я уже упоминал ранее, один из недостатков CFID и CFTOKEN заключается в том, что они показываются в адресной строке и их значения можно попытаться угадать. Значения CFID и CFTOKEN просто набор цифр. Подбирая различные варианты этих цифр, пользователь может выдать себя за другого пользователя (и это делается очень просто - указывая их в адресной строке).
Таким образом, еще одна новая возможность CFMX, которая ничего не делает с переменными J2EE сессий, заключается в том, что вы может генерировать для CFTOKEN более сложный UUID (Универсальный уникальный идентификатор). Эта возможность активизируется в оболочке Администратора на странице "server settings" отметив опцию "Use UUID for cftoken" (Тот факт, что эта опция находится не на странице "memory variables", говорит нам о том, что эта опция относится как к переменным сессий, так и к клиентским переменным). Чтобы изменения вступили в силу, следует перезапустить CFMX сервер. Для использования этой возможности никакие участки кода менять не нужно.После активизации этой возможности вы заметите, что теперь CFTOKEN выглядит примерно так: 15ce46ab4e29af0a-AF695847-F92F-344A-133252991FB6C3B5 (вы сами можете убедится в этом, запустив код <cfoutput>#cftoken#</cfoutput>). Несомненно, угадать такое значение на много сложнее! Такая возможность, вероятно, должна быть применена ко всем сайтам просто для дополнительной защиты. Единственная проблема может возникнуть в том, что по некоторым причинам ваш код зависит от CFTOKEN, длиной не более 8 символов (или если вы храните значения CFTOKEN в базе данных, то следует увеличить размер ее колонки).
Возможность использования UUID для CFTOKEN по сути не новость. Просто в CFMX ее легче активизировать. В версиях 4.5 и 5 следует вручную редактировать реестр. Об этом можно почитать здесь: www.macromedia.com/v1/Handlers/index.cfm?ID=22427&Method=Full.Использование переменных J2EE сессии
В начале этой статьи я упомянул, что CF теперь поддерживает J2EE сессии. Что это такое? И для чего они нам нужны? Ну, как программисту, возможно они дадут вам некоторые преимущества, но все-таки есть причины, по которым их использовать не следует. Для активизации этой возможности следует в оболочке Администратора на странице "memory variables" отметить опцию "Use J2EE session variables" и перезапустить CFMX сервер.
Принцип работы J2EE сессий заключается в том, что клиенту отправляются cookie не с CFID и CFTOKEN, а только с JSessionID (опять же, если тег cfapplication имеет параметр CLIENTMANAGEMENT=“yes”, то для поддержки только клиентских переменных дополнительно отправляются CFID и CFTOKEN).Разница между CFID/CFTOKEN и JSessionID заключается не только в их названиях. Во-первых, значением JSessionID является более сложный набор символов (включая UUID). Напомню, что значениями CFID и CFTOKEN является набор нескольких цифр, которые можно угадать. Кроме того, использование UUID в качестве значения CFTOKEN может уменьшить различия между этими двумя видами сессий.
Но есть еще различия, которые для некоторых людей могут быть очень важны. Самое крутое из них это то, что J2EE сессии работают так, как хотелось бы большинству разработчиков: когда пользователь закрывает свой броузер, то вместе с этим и уничтожается сессия. Аллелуя!Как это получается, что сессия "сгорает" сразу же после закрытия броузера? Возможно вы уже угадались: JSessionID, который используется для J2EE сессии, устанавливается как временные cookie. Это значит, что значение cookie хранится не на жестком диске пользователя, а в памяти броузера. Когда окно броузера закрыто, то и JSessionID потеряно. При последующем посещении через новое окно броузера, пользователю дается новый JSessionID.
Технически, сессия будет жить в памяти CFMX до тех пор, пока не истечет время ее существования. Но если от пользователя не исходят какие-либо действия, то сессия прекращается.Когда закрытие броузера прекращает сессию?Чтобы быть более точным, следует сказать, что сессия (с использованием переменных J2EE сессии) прекращается, когда закрыто последнее окно броузера. Если пользователь открыл несколько окон, например, Netscape'а, то только закрытие всех их прекратит сессию, т.к. все окна Netscape'а имеют доступ к одному и тому же JSessionID.
С Internet Explorer все немного по-другому. Окна будут хранить одну и ту же сессию, если все они были открыты командой File>New>Window или нажатием клавиш Ctrl-N. Но если вы открыли окно IE через Start>Programs>Internet Explorer, то в нем будет новая сессия.Это делает возможным прекратить сессии в одних окнах, оставляя активными другие окна. Опять же, закрытие все окон броузера приведет к прекращению всех сессий, использующих переменные J2EE сессий.
Также очевидно преимущество такой сессии для тех организаций, где запрещены использования постоянных cookie. Конечно, существуют способы использования временных cookie во всех версиях CF и об этом можно почитать здесь: www.macromedia.com/v1/Handlers/index.cfm?ID=21079&Method=Full. Но при использовании J2EE сессий об этом не стоит и беспокоится.
И еще одно, заключительное преимущество использования J2EE сессий, которое может впечатлить большинство CF разработчиков, заключается в том, что переменные сессий можно использовать совместно с программами JSP и сервлетами, работающими под управлением CFMX. Если вы начнете изучать эту возможность, то поймете на сколько она важна. Более подробно об этом вы можете почитать в руководстве по CFMX: Глава 32 - Developing ColdFusion MX Applications with CFML, доступном по адресу http://livedocs.macromedia.com.Заключение
В поддержке переменных сессий CFMX появилось больше возможностей, чем просто J2EE сессии. Первые две из них полезны всем CFMX разработчикам и также применимы и к клиентским переменным (а вторая применима даже в версиях CF 4.5 и 5). Эти возможности дабавляют новый уровень в обеспечении безопасности, "гибкости" и возможности. Остается только проверить их!
© 2002-2005 г. Вадим Пушкарев