что такое сессия в браузере
Кэш, куки и сессия браузера: применение в сфере тестирования ПО
С понятиями кэш, куки и сессия в браузере должен ознакомится каждый QA-инженер, который предоставляет услуги по тестированию веб-продуктов.
Очень часто, при «столкновении» с данными терминами, возникает много вопросов.
Чтобы максимально раскрыть каждое из данных понятий, узнать их области применения и алгоритм использования (исходя из применяемого браузера), рассмотрим каждое более детально.
Сookies (куки) – определенное количество информации, создающееся сервером после того, как пользователь посетил страницу, и которое остается на ПК пользователя как отдельный текстовый документ.
В основном, куки хранят идентификационную информацию, данные о пользователе, о характеристиках и настройках, которые были выбраны в процессе взаимодействия со страницей, а также другие подобные данные, относящиеся к служебным.
Если куки поддерживаются браузером, то при каждом следующем запросе весь объем информации транспортируется от пользователя на сервер. Какая польза для сайта от этих данных?
Как правило, идентификационная информация используется сервером, чтобы:
Если рассматривать куки с технической точки зрения, то это текстовые документы небольших размеров. Максимальный объем куки-файла – 4096 байт.
Что находится в документе куки:
Сессия
Веб-сервера имеют одну важную особенность, которая кроется в том, что они не могут распознавать откуда каждый раз поступают запросы (с одного и того же браузера или с разных).
Это происходит потому, что HTTP протокол «не разрешает» прослеживать ход этих состояний и, соответственно, поддерживать беспрерывную связь с посетителем.
Каждый запрос проходит обработку отдельно, без малейшей связи с прошедшими.
Данную проблему позволяет решить сессия браузера (сеанс) – механизм отслеживания запросов от одного браузера, способный сберечь некоторые переменные в процессе переходов между страницами веб-продукта.
Со стартом сессии, на сервере создается документ, где находятся данные о клиенте, его манипуляциях и событиях, произошедших в пределах одной сессии. Это может быть просматривание сайта, действия с составляющими деталями страниц, произведение транзакций и прочее.
Пока сеанс длится, новый начаться не может.
Предыдущая сессия закончится только в том случае, когда будет реализовано одно из условий (зависит от настроек):
Всем прекрасно известно, что для высокого качества работы в интернете, сайт должен быстро загружаться.
Увеличенное время ожидания отклика страницы может привести к тому, что посетитель просто закроет ее и перейдет на другую, более оптимизированную. Поэтому, в интересах разработчика, не допускать подобного.
Вся сложность ситуации в том, что сервер, при каждом обновлении страницы, транспортирует браузеру достаточно большой объем информации. Естественно, это негативно влияет на скорость работы сайта. Для решения этой проблемы и оптимизации веб-программ, создали кэш.
Например, ваша сеть интернет работает медленнее, нежели компьютер. С помощью кэша, браузер локально сохраняет определенную часть данных на ПК клиента.
Как результат, в повторной загрузке идентичной информации нет необходимости, требуемые данные просто грузятся из памяти ПК без подключения к сети.
Естественно, загрузка страницы, при таком раскладе, происходит значительно быстрее.
Что, в основном, хранится в кэше? Обычно страницы одного сайта имеют однотипный дизайн, в следствие этому, есть элементы сайта, которые дублируются на разных страницах.
Чтобы при каждом переходе не передавать одинаковый снимок, он локально загружается в файлы кэша и при обновлениях уже грузится с жесткого диска пользователя, а не через сервер.
Кроме логотипов, кэшироваться могут текстовые сообщения, видео-файлы, звук.
Кэш браузера ограничен в размере. Его максимальный объем настраивается. Когда хранилище кэша заполнено, то те данные, которые дольше всего не были в использовании, удаляются, тем самым освобождая пространство новым частям.
После того, как мы разграничили термины «сессия», «кэш» и «куки», перейдем к непосредственному процессу их применения.
В целом, обычному пользователю вполне хватить умений включить или выключить, отредактировать или удалить куки, произвести очистку кэша и суметь обнаружить данные документы на своем ПК.
Как выполнить очистку кэша на компьютере?
В первую очередь, нужно учитывать, какой браузер используется для работы.
Важно помнить, что кэш одного и того же веб-продукта, у разных браузеров, находится в различных файлах директории C:\Users\Admin\AppData\Local\.
Если такую папку вы не можете найти на своем ПК, следует просто в параметрах активировать демонстрацию скрытых файлов.
Каждый браузер в этой директории формирует свою файловую папку, где и находится кэш.
Представим наиболее распространенные браузеры:
Обнулить всю информацию из сайта, очистить кэш и куки можно непосредственно в браузере.
Для этого создана специальная функция, активацию которую можно выполнить в настройках.
Алгоритм у каждого из браузеров отличается, поэтому, рассмотрим подробнее процесс очистки кэша в них:
Также, существует еще один способ почистить кэш браузера, не используя его настройки. Это горячие клавиши: Ctrl+Shift+Del – для большого количества браузеров и –⌥(Option)+⌘(Command)+E для Safari на Mac.
Как найти куки на разных браузерах?
К примеру, чтобы обнаружить куки в Chrome, следует выполнить такой алгоритм действий:
Если говорить об Internet Explorer 11, то там путь выполнения немного другой: «Меню браузера» — «Свойства браузера» — «Конфиденциальность» — Сайты/Дополнительно. Здесь возможна работа с файлами куки для выбранных веб-сайтов.
Для просмотра значения сохраненных настроек определенного сайта, необходимо прибегнуть к средствам разработчика (клавиша F12). В пункте «Сеть» поданы списки запросов, а в «Файлы куки» — их данные.
Создание веб-продукта – очень динамичный процесс. Иногда, редактирование сайта осуществляется по несколько раз за день.
Любому тестировщику нельзя забывать о том, что перед выполнением непосредственной проверки продукта необходимо произвести очистку кэша.
Если не выполнить данное условие, большая вероятность того, что страница будет грузится из кэша и внедренных обновлений просто не будет видно.
Процедура сеанса подразумевает собой идентификацию браузера и обработку запросов в течение одного сеанса.
При этом, используются переменные из прошлых запросов. В основном, все данные о сессии находятся на сервере и скрыты от пользователя.
Когда QA-инженер знает сроки окончания сессии и может предвидеть поведение сайта при ее завершении, он легко напишет несколько сценариев для тестирования.
Очень часто, чтобы сайт работал корректно, нужно включить куки. При таком раскладе, проверку работы продукта можно осуществлять двумя способами: с включенными и отключенными куки.
Третий вариант проверки – редактирование куки вручную, с использованием как валидной, так и невалидной информации.
В файлах куки хранятся конфиденциальные данные пользователя для авторизации.
Применив определенный инструментарий для изменения этих данных, тестировщик может узнать, можно ли открыть доступ к аккаунту другого посетителя, отредактировав куки. Такой вид деятельности относят к тестированию безопасности.
При первом знакомстве с кэшем, сессий браузера и куки, все это кажется сложным и запутанным, но изучив терминологию и опробовав полученные знания в практической деятельности, убеждаешься, что здесь нет ничего тяжелого.
HTTP сессия
Так как HTTP — это клиент-серверный протокол, HTTP сессия состоит из трёх фаз:
Начиная с версии HTTP/1.1, после третьей фазы соединение не закрывается, так как клиенту позволяется инициировать другой запрос. То есть, вторая и третья фазы могут повторяться.
Установка соединения
Так как HTTP это клиент-серверный протокол, соединение всегда устанавливается клиентом. Открыть соединение в HTTP — значит установить соединение через соответствующий транспорт, обычно TCP.
В случае с TCP, в качестве порта HTTP сервера по умолчанию на компьютере используется порт 80, хотя другие также часто используются, например 8000 или 8080. URL загружаемой страницы содержит доменное имя и порт, который можно и не указывать если он соответствует порту по умолчанию.
Отправка запроса клиента
Когда соединение установлено user-agent может послать запрос. (user-agent это обычно веб браузер, но может им не быть) Клиентский запрос это текстовые директивы, разделённые между собой при помощи CRLF (переноса строки). Сам запрос включает в себя три блока:
Примеры запросов
Получаем главную страницу developer.mozilla.org, http://developer.mozilla.org/, и говорим серверу, что user-agent предпочитает страницу на французском, если это возможно:
Обращаем внимание на пустую строку в конце, которая отделяет блок данных от блока заголовков. Так как в запросе отсутствует Content-Length: HTTP заголовок, блок с данными пуст и сервер может начать обработку запроса, как только получит пустую строку, означающую конец заголовков.
Отправляем результат сабмита формы:
Методы запроса
HTTP определяет набор методов запроса с указанием желаемого действие на ресурсе. Хотя они также могут быть и существительными, эти запросы методы иногда называют HTTP-командами. Наиболее распространённые запросы GET и POST :
Структура ответа от сервера
После того как присоединённый агент отправил свой запрос, веб сервер обрабатывает его и отправляет ответ. По аналогии с клиентским запросом, ответ сервера — это текстовые директивы разделённые между собой CRLF, сгруппированные в три разных блока:
Примеры ответов
Успешное получение веб страницы:
Сообщение о том, что запрашиваемый ресурс был перемещён:
Сообщение о том, что запрашиваемый ресурс не существует:
Коды статусов ответа
HTTP-коды ответов показывают, выполнен ли успешно определённый HTTP-запрос. Ответы сгруппированы в пять классов: информационные ответы, успешные ответы, редиректы, ошибки клиента и ошибки сервера.
Сессии. Подробное описание работы и объяснение механизма.
Подробно расписывать нужду в таком механизме я не буду. Это такие хрестоматийнык случаи, как корзина покупок в е-магазине, авторизация, а так же, и не совсем тривиальные проблемы, такие, например, как защита интерактивных частей сайта от спама.
В принципе, довольно несложно сделать собственный аналог сессий, не такой функциональный, как встроенный в PHP, но похожий по сути. На куках и базе данных.
При запросе скрипта смотрим, пришла ли кука с определенным именем. Если куки нет, то ставим ее и записываем в базу новую строку с данными пользователя. Если кука есть, то читаем из базы данные. Еще одним запросом удаляем из базы старые записи и вот у нас готов механизм сессий. Совсем несложно. Но есть некоторые нюансы, которые делают предпочтительным использование именно встроенного механизма сессий.
Если включена только первая, то при старте сессии (при каждом вызове session_start() ) клиенту устанавливается кука. Браузер исправно при каждом следующем запросе эту куку возвращает и PHP имеет идентификатор сессии. Проблемы начинаются, если браузер куки не возвращает. В этом случае, не получая куки с идентификатором, PHP будет все время стартовать новую сессию, и механизм работать не будет.
По умолчанию в последних версиях PHP включены обе опции. Как PHP поступает в этом случае? Кука выставляется всегда. А ссылки автодополняются только если РНР не обнаружил куку с идентификатором сессии. Когда пользователь в првый раз за этот сеанс заходит на сайт, ему ставится кука, и дополняются ссылки. При следующем запросе, если куки поддерживаются, PHP видит куку и перестает дополнять ссылки. Если куки не работают, то PHP продолжает исправно добавлять ид к ссылкам, и сессия не теряется.
Пользователи, у которых работают куки, увидят длинную ссылку с ид только один раз.
Следует помнить, что пхп лочит файл сессии. То есть, если один ваш скрипт стартует сессию и долго выполняется, а другой пытается в это время стартовать её с тем же идентификатором, то он зависнет. Поэтому в долго выполняющихся скриптах следует стартовать сессию только тогда, когда она нужна, и тут же закрывать её, с помощью session_write_close()
Все, что нужно знать о сессии на сайте
Под сессией принято понимать строго обозначенный промежуток времени, на протяжении которого пользователь пребывает на сайте. Все пользователи для входа в интернет используют специальные программы – браузеры. Идентификация пользователя в интернете осуществляется с учетом его персональных данных, речь идет о cookies-файлах и IP-адресе.
Протяженность сеанса пользователя на сайте определяется исходя из промежутка между первым и последним действием, совершенным им на сайте. Практика показывает, что в ходе измерения протяженности сеанса возникают трудности. В первую очередь это обусловлено отсутствием возможности постоянного контроля над временем просмотра страницы, на которую перешел пользователь по ссылке. На данный момент не существует программного обеспечения, способного выполнять такие задачи.Чтобы разобраться в том, что такое сессия на сайте, рассмотрим следующий пример:
Сессия как событие в сервисах аналитики применяется с целью наблюдения за поведением пользователей, посещающих сайт. Сессия напрямую взаимосвязана со следующими метриками:
На данный момент сессия как событие характеризуется широкой областью применения, одним из вариантов ее использования могут быть следующие сценарии:
В рамках данной статьи мы будем рассматривать сессию применительно к сайту и веб-аналитике. В данном случае сессия выступает в качестве инструмента для определения последовательности запросов, выполняемых пользователем.
Если рассматривать сессию с точки зрения отдельного события, то речь идет о совокупности запросов, отправляемых от лица клиента в момент его взаимодействия с хостом/сервером. Клиент может быть представлен не только в виде браузера, но и в виде поискового робота или веб-приложения. Хост в большинстве случаев – это сайт.
Сессия может включать в себя все запросы, совершенные клиентом на протяжении строго обозначенного промежутка времени.
Сервер самостоятельно классифицирует запросы, поступающие от клиента. Сейчас широко применяется идентификация запроса – cookies-файл, важно отметить, что помимо него существуют и другие варианты. В качестве примера можно рассмотреть идентификацию запросов клиента посредством обращения к параметрам запроса, MAC-адресу, что стало возможным благодаря расширенным HTTP-заголовкам.
Для удаления сессии задействуется функция session_destroy(). Посредством одного вызова можно осуществить удаление всех переменных сеанса. Для удаления одной переменной сессии рекомендуется обратиться к функции unset(), которая дает возможность произвести отключение необходимой переменной.
Каждый сайт содержит в себе не только вход, но и выход, который представлен в виде специального сценария, его основной целевой задачей является комплексная очистка сессии, после этого пользователь попадает на главную страницу.
Если рассматривать сессию в ее взаимосвязи с сайтом, то речь идет о многоаспектном понятии. При этом на практике чаще оно используется в тех случаях, когда возникает необходимость в составлении отчетов веб-аналитики. Комплексное изучение сессии как события позволит увеличить эффективность анализа отчетов веб-аналитики.
HTTP сессия. Session. Состояние сеанса. Работа с сессиями в ASP.NET MVC
Давайте рассмотрим такое понятие как сессия (HTTP-сессия, Session). Или по-другому, сеанс пользователя. Почему важно понимать механизм работы сессий. И посмотрим, как можно работать с состояниями сеансов на платформе ASP.NET.
Прежде чем мы дадим определение термину «сессия», давайте немного рассмотрим предысторию, зачем вообще возникла потребность в сессиях, рассмотрим одну особенность протокола HTTP.
Одной из основных особенностей протокола HTTP является то, что он не обязывает сервер сохранять информацию о клиенте между запросами, то есть идентифицировать клиента. Это так называемый stateless-протокол. Связь между клиентом и сервером заканчивается как только завершается обработка текущего запроса. Каждый новый запрос к серверу подразумевается как абсолютно уникальный и независимый, даже если он был отправлен повторно от одного и того же источника.
Что, если оставить stateless-природу протокола HTTP и не идентифицировать пользователя? Без состояний сеанса можно легко обойтись, если на вашем сайте представлена статичная (обезличенная) информация, например, новостная статья, состоящая из текста и изображений. В таком контексте совершенно необязательно ассоциировать несколько запросов с одним пользователем. Ведь содержание статьи никак не изменится, будь то десять запросов с одного устройства, либо десять запросов от разных людей с разных устройств.
Но как только мы собираемся передать персональную информацию на сервер, нам необходимо каким-то образом сделать так, чтобы сервер ассоциировал все наши запросы именно с нами, и в будущем верно определял все исходящие от нас запросы. Если этого не сделать, то с каждым новым запросом мы будем вынуждены повторно передавать необходимые персональные данные. Например, логин для входа в личный кабинет на сайте, или такую информацию как имя, адрес доставки, при совершении покупки в интернет-магазине.
Вот как раз в таких ситуациях, когда требуется персонализировать запросы от одного клиента, мы будем использовать сессии.
Когда клиент впервые передает персональные данные в запросе, на сервере создается новая сессия для этого клиента. В период времени жизни сессии все запросы от этого клиента будут однозначно распознаны и связаны с ним. По истечении этого времени связь с клиентом будет потеряна, и очередной запрос от него будет обрабатываться как абсолютно уникальный, никак не связанный с предыдущими.
Например, при совершении покупки в онлайн магазине персональная информация пользователя сохраняется в сессии, пока он путешествует по сайту. Это выбранные товары в корзине, адрес доставки, контактные данные и так далее.
Теперь давайте посмотрим, как это мы можем реализовать технически. Вообще существует несколько техник управления сессиями клиента, их количество и способ реализации во многом зависит от веб-платформы или технологии, что работает на сервере. В этом уроке мы рассмотрим следующие:
Попробуем их реализовать, используя платформу ASP.NET. Давайте кратко рассмотрим первые два механизма, и особое внимание уделим третьему, как более надежному, удобному и безопасному.
Скрытые поля на HTML-форме (hidden form fields)
Суть данного подхода состоит в том, что мы обеспечиваем навигацию по сайту при помощи стандартных html-форм. И при каждом следующем запросе мы сохраняем данные из предыдущего в скрытых полях на форме. Например:
Давайте рассмотрим особенности такого подхода. Плюсов практически нет, разве что реализовать данную технику можно очень быстро. Но опять же и другие подходы тоже можно реализовать очень быстро. А вот минусы есть, и довольно существенные:
Куки (cookies)
В данном подходе мы не храним сессионные данные непосредственно на форме, вместо этого используется стандартный механизм работы cookies между клиентом и сервером. В cookies и хранятся все пользовательские данные.
При выборе этого подхода опять же главной остается проблема безопасности наших данных, которые мы передаем на сервер – их легко подменить или украсть, они лежат в открытом виде. Также, если в настройках приватности браузера клиента отключен прием куки с сайтов, то такой вариант ведения сессии вовсе не будет работать.
Серверный механизм управления сессией (Session, SessionState)
Разберем, как работает механизм сессии со стороны сервера и со стороны клиента.
При стандартных настройках работы состояния сеанса для отслеживания серии запросов от одного клиента используется т.н. сессионная куки (session cookie). Алгоритм следующий:
В этом участке кода мы записываем в состояние сеанса имя пользователя. Это имя мы забираем с html-формы, которую он нам отправил. Дополнительно через свойства мы узнаем, создана ли эта сессия только что, то есть в рамках текущего запроса (если да, то и значение свойства IsNewSession будет равняться true), и уникальный идентификатор сессии. Этот идентификатор после обработки запроса будет автоматически записан в сессионную куки (если еще нет) и отправлен в ответе клиенту.
В браузере клиента можно наблюдать соответствующую куки и идентификатор его сессии:
В процессе следующего запроса от этого клиента давайте прочитаем его ранее сохраненное имя из сессии. Также принудительно завершим сессию. Работа с этим клиентом закончена, например, все данные обработаны и товар отправлен.
Как видно, работать с сессиями очень просто и удобно. Большинство процессов, связанных с обработкой сессии, происходит автоматически в фоновом режиме. Естественно, разработчик может вмешаться на любой стадии обработки сессии и внести свои коррективы.
В конфигурации выше мы указали, что таймаут сессии будет 40 минут, сессионные данные пользователя будут храниться в оперативной памяти, будут использоваться сессионные куки, также поменяли стандартное название такой куки на собственное.