как узнать сессию пользователя
Как определить кто открыл файлы в сетевой папке и сбросить сессии пользователя в Windows Server
На общедоступном сетевом ресурсе могут возникать ошибки доступа к файлам. Причиной этому является некорректно завершенная сессия пользователя, ошибки в работе ПО или просто кто-то открыл файл и не закрывает его. В такой ситуации файл оказывается заблокированным и не доступен для работы другим пользователям.
Решить проблему доступа к файлу можно путем закрытия сеансов использующих этот файл. В этой статье я расскажу как определить кто открыл файл в сетевой папке и как закрыть это подключение.
Рассмотрим два способа:
1 способ. Получаем список открытых файлов с помощью оснастки «Управление компьютером».
Для получения списка открытых файлов на файловом сервере воспользуемся оснасткой консоли «Управление компьютером». Для запуска оснастки нажимаем сочетание клавиш «Win + R» и набираем название оснастки «compmgmt.msc».
В иерархии оснастки переходим /Управление компьютером/Служебные программы/Общие папки/Открытые файлы.
В правой части оснастки появится список открытых файлов. Здесь можно увидеть имя пользователя открывшего файл, количество блокировок и режим доступа к файлу.
Закрываем файл. Чтобы закрыть сетевой файл открытый другим пользователем находим его в списке и в контекстном меню выбираем пункт «Закрыть открытый файл».
2 способ. Просмотр открытых файлов через командную строку утилитой Openfiles.
Утилита Openfiles дает нам более широкие возможности по поиску и закрытию заблокированных файлов.
C помощью openfiles можно просмотреть список открытых файлов на сервере удаленно. Для этого открываем командную и запускаем утилиту с параметрами.
По-умолчанию список файлов показан в формате таблицы, но есть параметры позволяющие изменить формат вывода:
Если необходимо увидеть информацию о количестве блокировок файлов (#Locks) и в каком режиме открыт файл (чтение или запись), то можно воспользоваться параметром /v.
Определяем кто открыл сетевой файл.
Чтобы найти пользователя, который открыл и заблокировал нужный нам файл запускаем Openfiles с командой find.
в команде find указан параметр /i, чтобы поиск был регистронезависимым.
После того когда мы узнали имя пользо
Закрываем заблокированный сетевой файл.
Закрыть открытый файл можно по id сессии таким способом:
Закрыть все сетевые подключения к файлам и папкам, которые открыл пользователь BadUser:
Закрыть все файлы и директории открытые в режиме чтение/запись:
Закрыть все подключения к директории с именем «c:\myshare»:
Чтобы сбросить все сессии на удаленном сервере FileServer, которые открыл пользователь domain\baduser, независимо от id сессии:
Как узнать сессию пользователя
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами разобрали, как сделать таймер выключения компьютера. Сегодня я хочу вас научить определять ID (Уникальный идентификатор) и номер сеанса пользователя на терминальных столах. Уметь, это нужно, для решения ситуаций, когда такой сеанс зависает и пользователь не может работать и переключиться на другую ноду RDS фермы, так как посредники подключений видят, что у него есть активная сессия. Думаю. что мой опыт, описанный в статье окажется вам полезным.
Что такое ID сеанса
Когда пользователь входит на компьютер с включенными службами удаленных рабочих столов, для него запускается сеанс. Каждый сеанс идентифицируется уникальным идентификатором сеанса. Каждый такой сеанс ассоциируется с интерактивной оконной станцией (interactive window station) «WinSta0»; поэтому каждый сеанс связан со своей собственной оконной станцией «WinSta0». Для каждой оконной станции имеется три стандартных рабочих стола: рабочий стол Winlogon, рабочий стол с заставкой и интерактивный рабочий стол.
Когда пользователь выходит с сервера удаленных рабочих столов (RDC), то сеанс, который клиент имеет на сервере узла сеансов удаленных рабочих столов (ранее назывался сервер терминалов), удаляется. Однако если сеанс консоли служб удаленных рабочих столов не смог завершится, то оконные станции, связанные с сеансом консоли, не удаляются, все процессы продолжают висеть. Это влияет на поведение приложений в среде служб удаленных рабочих столов, когда они настроены для работы в контексте безопасности интерактивного пользователя, также известного как режим активации объекта «RunAs Interactive User». Вот тогда, то и выявляется ID сеанса, чтобы его грохнуть.
Методы определения ID сеанса пользователя RDP
Существует несколько методов, которые могут вам помочь определить номер сеанса и его ID на терминальных серверах и RDS фермах.
Определение ID сеанса через quser
И так у меня есть RDS ферма состоящая из хостов с Windows Server 2012 R2, в базе Active Directory есть пользователь Барбоскин Геннадий Викторович. Данный пользователь вошел на терминал, работал, но по какой-то причине он завис и чтобы корректно разлогинить его сессию нам необходимо вычислить ее номер сеанса и уникальный идентификатор. Попробуем это выполнить через утилиту quser.
Вы можете использовать эту команду, чтобы выяснить, вошел ли конкретный пользователь на конкретный сервер Session Host. Команда возвращает:
Откройте командную строку cmd, лучше в режиме администратора и введите команду:
У вас будет выведен список всех текущих сессий на вашем терминальном сервере.Если пользователей много, то сложно сразу найти нужного, так как все идет не по алфавиту. Ранее я вам показывал, как фильтровать вывод результатов в командной строке Windows, там была команда findstr. Вводим команду:
В итоге я вижу, что номер сеанса rdp-tcp#24 и его ID 45, статус активно, это означает, что человек работает. Видно его время входа. Тот же результат можно получить и вот такой конструкцией:
Вы наверное спросите, почему сразу так не ввели, все просто, я лишь еще раз напомнил вам, о фильтрации в cmd, которая работает почти с любой командой, так сказать универсальный ключ.
Так же есть возможность запустить для конкретного сервера, для этого есть ключ /server
Определение ID сеанса через qwinsta
Для того, чтобы получить номер сеанса с ID, введите в командной строке:
Утилита выведет список всех авторизованных в системе пользователей, из полезной информации вы получите:
Чтобы вывести определенного пользователя, введите команду:
Как узнать id пользователя через диспетчер задач
Покажу и графический метод. который позволяет вам получать ID и номер сеанса на терминальных столах. Откройте диспетчер задач и перейдите на вкладку «Пользователи». У вас будет отображен список сотрудников. Тут для удобства их можно выстроить по алфавиту. Все хорошо, но нет ID и номера сеанса.
Чтобы включить отображение нужных нам столбцов, вам необходимо щелкнуть правым кликом на область с именем столбцов. В контекстном меню поставьте галки на «Код» и «Сеанс».
В итоге у вас теперь появилась возможность легко просматривать идентификационный код сеанса и имя сеанса, в моем примере, это RDP-Tcp#24.
Как узнать id пользователя через query session
Получение информации о сеансе через Get-TerminalSession
PowerShell не зря называют могучим, он поистине может все. К сожалению родных командлетов, которые бы заменяли утилиты командной строки нет, но есть возможность установить дополнительные, из репозитория. Речь пойдет, о сборнике «PowerShell Community Extensions» (Pscx 3.2.2). Данный сборник включаем в себя огромный комплекс командлетов, нас будет интересовать Get-TerminalSession.
Установка «PowerShell Community Extensions» очень проста и выполняется одной командой. Перед установкой Pscx 3.2.2, вам необходимо обновить ваш PowerShell хотя бы до версии 5.1. Далее запускаете оболочку PowerShell от имени администратора и вводите команду:
Про сам сборник вы можете почитать по ссылке (https://www.powershellgallery.com/packages/Pscx/3.2.2)
Получение информации о сеансе через Get-TSSession
Модуль PSTerminalServices, так же позволяет взаимодействовать с терминальными профилями В состав PSTerminalServices входят вот такие командлеты:
Скачать PSTerminalServices вы можете по ссылке https://github.com/imseandavis/PSTerminalServices, там будет MSI пакет, если его уже по какой-то причине не будет, то можете загрузить PSTerminalServices по ссылке слева.
Установка PSTerminalServices проста до безобразия. На первом экране нажимаем «Next».
При необходимости изменяем путь установки данного модуля.
Для продолжения нажимаем «Install»
Установка модуля завершена.
Теперь, чтобы модуль запускался вам нужно разрешить запуск скриптов, напоминаю, что для текущего пользователя, это можно сделать вот так:
Далее проверьте командой, что модуль PSTerminalServices доступен в системе, выполните:
Далее импортируем модуль и запускаем его:
На выходе вы получаете информацию, о всех ваших сеансах пользователей на терминальном столе
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 минут, сессионные данные пользователя будут храниться в оперативной памяти, будут использоваться сессионные куки, также поменяли стандартное название такой куки на собственное.
7 способов посмотреть, кто работает на сервере терминалов
С чего начинается администрирование пользователей на сервере терминалов?
Конечно с просмотра «Активных» или «Отключенных» сессий пользователей.
Без этой картины администрирование сервера терминалов невозможно.
Помимо статьи, записал также, и подробное видео, о том как администрировать пользователей на сервере терминалов (Новичкам смотреть обязательно!)
Конечно, данная тема также подымается и на курсе: Администратор 1С!
И так, конечно мы должны во всех подробностях видеть, что у нас происходит на сервере терминалов!
Какие процессы запущены от имени тех или иных пользователей (в т.ч. процессы 1С) их идентификаторы, id сессий пользователей, это и многое другое помогает администратору всегда быть в курсе того что происходит на сервере и соответственно всем этим управлять, и вовремя реагировать на различные ситуации.
На разных версиях Windows server администраторы по-разному решают этот вопрос.
Но все администраторы хотят одного:
1. Чтоб быстро посмотреть всех пользователей кто работает на сервере.
2. Чтоб это было как можно информативней.
Поэтому поводу решил собрать все лучшие, простые и быстрые способы которые (на мое мнение) стоит использовать.
Уверен, что многим начинающим администраторам эти способы помогут в администрировании сервера терминалов.
И так способ первый и самый простой (На Windows server 2012 R2)
1. Диспетчер задач.
«Диспетчер задач» – вкладка «Пользователи» – позволяет нам видеть пользователей, которые работают на этом сервере.
Но по умолчанию стандартный «Диспетчер задач» – вкладка «Пользователи» нам не покажет, что пользователь работает на сервере удаленно, используя RDP, хорошо, что это можно легко исправить.
Правый клик мышкой на панели «Пользователь» и в появившимся контекстном меню
ставим птичку напротив «Сеанс» а также стоит поставить и напротив «Имя клиента».
Так мы будем знать, что этот пользователь работает у нас на сервере через RDP.
Минусы данного способа здесь очевидны, чтоб смотреть пользователей мы должны находится на сервере терминалов, где собственно и запускаем «Диспетчер задач», нет возможности сделать какую-то выборку, фильтр и т.д.
2. quser
Следующий метод это использование команды quser в CMD или PowerShell.
Quser – это аналог QUERY USER (Такое сокращение позволяет выполнять команду быстрее)
Здесь все просто запускаем CMD или PowerShell и пишем команду quser
Так мы увидим всех пользователей, что работают на этом сервере.
Метод очень простой быстрый и достаточно информативный.
Если мы хотим посмотреть только какого-то конкретного пользователя, тогда можно написать например так:
Term01 – это логин пользователя.
Большинство системных администраторов отдают предпочтение именно этому способу.
И не только потому, что быстро, просто и т.д., но и потому что можно смотреть удаленно всех пользователей, сидя за своим ПК, где не будь в локальной сети.
И для этого достаточно ввести команду с параметром SERVER
Вместо IP можно указать (хост) имя сервера терминалов.
Формат командной строки:
QUSER [; пользователь ; | ; имя сеанса ; | ; ID сеанса ;] [/SERVER:; сервер ;]
Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С
PHP для начинающих. Сессия
Начну с сессий — это один из самых важных компонентов, с которыми вам придется работать. Не понимая принципов его работы — наворотите делов. Так что во избежание проблем я постараюсь рассказать о всех возможных нюансах.
Но для начала, чтобы понять зачем нам сессия, обратимся к истокам — к HTTP протоколу.
HTTP Protocol
Изначально подразумевали, что по этому протоколу будет только HTML передаваться, отсель и название, а сейчас чего только не отправляют и =^.^= и（•_ㅅ_•）
Чтобы не ходить вокруг да около, давайте я вам приведу пример общения по HTTP протоколу.
Вот пример запроса, каким его отправляет ваш браузер, когда вы запрашиваете страницу http://example.com :
А вот пример ответа:
Это очень упрощенные примеры, но и тут можно увидеть из чего состоят HTTP запрос и ответ:
Т.е. если украсть cookie из вашего браузера, то можно будет зайти на вашу страничку в facebook от вашего имени? Не пугайтесь, так сделать нельзя, по крайней мере с facebook, и дальше я вам покажу один из возможных способов защиты от данного вида атаки на ваших пользователей.
Давайте теперь посмотрим как изменятся наши запрос-ответ, будь там авторизация:
Метод у нас изменился на POST, и в теле запроса у нас передаются логин и пароль. Если использовать метод GET, то строка запроса будет содержать логин и пароль, что не очень правильно с идеологической точки зрения, и имеет ряд побочных явлений в виде логирования (например, в том же access.log ) и кеширования паролей в открытом виде.
Как можно заметить, заголовки отправляемые браузером (Request Headers) и сервером (Response Headers) отличаются, хотя есть и общие и для запросов и для ответов (General Headers)
Сервер узнал нашего пользователя по присланным cookie, и дальше предоставит ему доступ к личной информации. Так, ну вроде с сессиями и HTTP разобрались, теперь можно вернутся к PHP и его особенностям.
PHP и сессия
Я надеюсь, у вас уже установлен PHP на компьютере, т.к. дальше я буду приводить примеры, и их надо будет запускать
Вот вам статейка на тему PHP is meant to die, или вот она же на русском языке, но лучше отложите её в закладки «на потом».
Перво-наперво необходимо «стартовать» сессию — для этого воспользуемся функцией session_start(), создайте файл session.start.php со следующим содержимым:
Запустите встроенный в PHP web-server в папке с вашим скриптом:
Запустите браузер, и откройте в нём Developer Tools (или что там у вас), далее перейдите на страницу http://127.0.0.1:8080/session.start.php — вы должны увидеть лишь пустую страницу, но не спешите закрывать — посмотрите на заголовки которые нам прислал сервер:
Там будет много чего, интересует нас только вот эта строчка в ответе сервера (почистите куки, если нет такой строчки, и обновите страницу):
Увидев сие, браузер сохранит у себя куку с именем `PHPSESSID`:
PHPSESSID — имя сессии по умолчанию, регулируется из конфига php.ini директивой session.name, при необходимости имя можно изменить в самом конфигурационном файле или с помощью функции session_name()
И теперь — обновляем страничку, и видим, что браузер отправляет эту куку на сервер, можете попробовать пару раз обновить страницу, результат будет идентичным:
Итого, что мы имеем — теория совпала с практикой, и это просто отлично.
Обновляем страничку и видим время сервера, обновляем ещё раз — и время обновилось. Давайте теперь сделаем так, чтобы установленное время не изменялось при каждом обновлении страницы:
Обновляем — время не меняется, то что нужно. Но при этом мы помним, PHP умирает, значит данную сессию он где-то хранит, и мы найдём это место…
Всё тайное становится явным
В вашей конфигурации путь к файлам может быть не указан, тогда файлы сессии будут хранится во временных файлах вашей системы — вызовите функцию sys_get_temp_dir() и узнайте где это потаённое место.
Так, идём по данному пути и находим ваш файл сессии (у меня это файл sess_dap83arr6r3b56e0q7t5i0qf91 ), откроем его в текстовом редакторе:
Как видим — вот оно наше время, вот в каком хитром формате хранится наша сессия, но мы можем внести правки, поменять время, или можем просто вписать любую строку, почему бы и нет:
Так, что мы ещё не пробовали? Правильно — украсть «печеньки», давайте запустим другой браузер и добавим в него теже самые cookie. Я вам для этого простенький javascript написал, скопируйте его в консоль браузера и запустите, только не забудьте идентификатор сессии поменять на свой:
Вот теперь у вас оба браузера смотрят на одну и туже сессию. Я выше упоминал, что расскажу о способах защиты, рассмотрим самый простой способ — привяжем сессию к браузеру, точнее к тому, как браузер представляется серверу — будем запоминать User-Agent и проверять его каждый раз:
Ключевое слово в предыдущем абзаце похоже, в реальных проектах cookies уже давно «бегают» по HTTPS протоколу, таким образом никто их не сможет украсть без физического доступа к вашему компьютеру или смартфону
Стоит упомянуть директиву session.cookie-httponly, благодаря ей сессионная кука будет недоступна из JavaScript’a. Кроме этого — если заглянуть в мануал функции setcookie(), то можно заметить, что последний параметр так же отвечает за HttpOnly. Помните об этом — эта настройка позволяет достаточно эффективно бороться с XSS атаками в практически всех браузерах.
По шагам
А теперь поясню по шагам алгоритм, как работает сессия в PHP, на примере следующего кода (настройки по умолчанию):
А есть ли жизнь без «печенек»?
PHP может работать с сессией даже если cookie в браузере отключены, но тогда все URL на сайте будут содержать параметр с идентификатором вашей сессии, и да — это ещё настроить надо, но оно вам надо? Мне не приходилось это использовать, но если очень хочется — я просто скажу где копать:
А если надо сессию в базе данных хранить?
Отдельно замечу, что не надо писать собственные обработчики сессий для redis и memcache — когда вы устанавливаете данные расширения, то вместе с ними идут и соответствующие обработчики, так что RTFM наше всё. Ну и да, обработчик нужно указывать до вызова session_start() 😉
Когда умирает сессия?
За время жизни сессии отвечает директива session.gc_maxlifetime. По умолчанию, данная директива равна 1440 секундам (24 минуты), понимать её следует так, что если к сессии не было обращении в течении заданного времени, то сессия будет считаться «протухшей» и будет ждать своей очереди на удаление.
Интересен другой вопрос, можете задать его матёрым разработчикам — когда PHP удаляет файлы просроченных сессий? Ответ есть в официальном руководстве, но не в явном виде — так что запоминайте:
Самая тривиальная ошибка
Ошибка у которой более полумиллиона результатов в выдаче Google:
Cannot send session cookie — headers already sent by
Cannot send session cache limiter — headers already sent
Для получения таковой, создайте файл session.error.php со следующим содержимым:
Во второй строке странная «магия» — это фокус с буфером вывода, я ещё расскажу о нём в одной из следующих статей, пока считайте это лишь строкой длинной в 4096 символов, в данном случае — это всё пробелы
Для проверки полученных знаний, я хочу, чтобы вы реализовали свой собственный механизм сессий и заставили приведенный код работать:
Блокировка
Ещё одна распространённая ошибка у новичков — это попытка прочитать файл сессии пока он заблокирован другим скриптом. Собственно, это не совсем ошибка, это недопонимание принципа блокировки 🙂
Но давайте ещё раз по шагам:
«Воткнутся» в данную ошибку очень легко, создайте два файла:
Есть пару вариантов, как избежать подобного явления — «топорный» и «продуманный».
«Топорный»
Использовать самописный обработчик сессий, в котором «забыть» реализовать блокировку 🙂
Чуть лучше вариант, это взять готовый и отключить блокировку (например у memcached есть такая опция — memcached.sess_locking) O_o
Потратить часы на дебаг кода в поисках редко всплывающей ошибки…
«Продуманный»
Куда как лучше — самому следить за блокировкой сессии, и снимать её, когда она не требуется:
— Если вы уверенны, что вам не потребуется вносить изменения в сессионные данные используйте опцию read_and_close при старте сессии:
Таким образом, блокировка будет снята сразу по прочтению данных сессии.
— Если вам таки нужно вносить изменения в сессию, то после внесения оных закрывайте сессию от записи:
В заключение
В этой статье вам дано семь заданий, при этом они касаются не только работы с сессиями, но так же познакомят вас с MySQL и с функциями работы со строками. Для усвоения этого материала — отдельной статьи не нужно, хватит и мануала по приведенным ссылкам — никто за вас его читать не будет. Дерзайте!