Как работает браузер php
HTML файл содержит текст страницы и специальные теги (метки) вроде , которые разбивают этот текст на абзацы, заголовки, позволяют добавлять в него ссылки, картинки, формы и многое другое. Ты можешь увидеть полученный от сервера HTML-код любой страницы в интернете, зайдя на нее и нажав Ctrl + U в браузере или выбрав в меню что-то вроде "Вид" - "Показать исходный код страницы".
Заголовок Content-Type влияет на то, как именно браузер отобразит содержимое. Если там будет например указано image/png , то браузер будет воспринимать тело ответа как картинку в формате PNG и попытается его отобразить. Конструкция вроде image/png называется MIME-тип, она состоит из 2 частей: общего типа данных ( image , text , audio ) и конкретного формата файла. Подробнее про MIME-типы можно почитать в Википедии.
Этот ответ отличается от предыдущего кодом состояния. В данном случае он равен 404 , что значит "запрошенный файл отсутствует на сервере". Тело ответа содержит HTML-код с текстом ошибки ("Page . not found on this server"), которая будет показана пользователю.
Вот самые распространенные коды состояний:
- 200 Ok - все ок, тело ответа содержит запрошенный файл
- 500 Internal Server Error - сервер не смог обработать запрос из-за ошибки на нем
- 404 Not Found - запрошенный файл не был найден на сервере (скорее всего, неправильно указан URL в запросе)
- 403 Access Denied - доступ к запрошенному файлу запрещен
- 301 Moved Permanently - запрошенный файл находится теперь по другому адресу, который указан в заголовке ответа Location . Браузер должен сделать новый запрос по этому адресу.
- если тебе интересно, можешь глянуть полный список кодов состояний в Википедии
Этот запрос точно так же содержит стартовую строку, заголовки запроса, и тело запроса (в GET-запросе выше тела не было), в котором передаются введенные в форму пользователем данные (логин и пароль). Заголовок Content-Type указывает, что в теле содержатся данные из формы и указывает способ их кодирования, а заголовок Content-Length содержит размер данных в байтах.
Что отправит сервер в ответ на этот запрос, зависит от того, как программа на сервере будет обрабатывать эти данные.
Статические и динамические страницы
Например, статический сайт хорошо подходит для публикации документации, информационного сайта, финансового отчёта, книги, какой-то информации, которая редко обновляется.
Также, статический сайт имеет одну особенность: так как это просто набор файлов, то его можно просматривать даже без веб-сервера и связи с интернетом. Достаточно сохранить HTML-файл со страницей себе на компьютер (например, нажав Ctrl + S в браузере), после этого её можно открыть и просмотреть в браузере (дважды кликнув или перетащив его в окно браузера). Или можно сделать архив с содержимым сайта и раздавать пользователям.
Динамические сайты сложнее сделать, в них чаще бывают ошибки, при неправильном написании возможны уязвимости, они сильнее нагружают процессор и память сервера (на 2019 год типичный статический сайт может обработать десятки тысяч запросов в секунду, а динамический - несколько сотен), но зато они позволяют реализовать взаимодействие с пользователями. Например, при отправке пользователем комментария программа может добавлять его в базу данных и он появится на странице.
Также, на динамическом сайте возможно сделать редактирование и добавление информации на сайт не с помощью правки кода, а через "админку" ("админка" - это административный интерфейс, закрытая часть сайта, позволяющая управлять им). Это позволяет заказать разработку сайта, а далее обновлять его без участия программиста и необходимости оплачивать его труд. Потому большинство сайтов в интернете - динамические.
Наконец, возможны и смешанные подходы. Например, можно сделать динамический сайт с ограниченным доступом, на котором производится редактирование информации, и публичный сайт на статической схеме. Редактор добавляет информацию на динамическом сайте, жмет кнопку публикации, и генерируется статическая копия сайта, которая выгружается на публично доступный сервер. Это позволяет совместить плюсы обоих подходов. По такой схеме работают некоторые государственные сайты.
Итак, для того, чтобы отобразить в браузере какую-то страницу, нам нужен веб-сервер (чтобы отвечать на запросы браузера). Есть несколько разных программ-серверов, например Apache, Nginx, но мы начнем с изучения простого веб-сервера, встроенного в интерпретатор php.
Сначала нам необходимо установить PHP себе на компьютер (или получить доступ к линукс-серверу, где он уже установлен). Как именно устанавливать PHP, зависит от операционной системы:
- для Windows - инструкции описаны в уроке по установке PHP на Windows
- для линукс - способ зависит от используемого дистрибутива. Например, в дебиан или убунту это делается командой sudo apt-get install php5 , в других дистрибутивах - немного другой командой. Погугли
- для MacOS X - погугли
- для андроида - придется помучиться. На июль 2016 года актуальна такая последовательность действий: для начала надо установить scripting layer for android - скорее всего его нет в Google Play, и надо установить apk файл вручную (будь осторожен, то что в Google Play находится по словам sl4a - это какие-то посторонние приложения). Затем из этого приложения надо установить PHP. И тогда появится возможность открыть окно командной строки и запускать сам PHP.
PHP - это программа командной строки. Это значит, что у него нет никакого графического интерфейса с кнопками и окнами, а для выполнения какого-то действия надо набрать в командной строке правильную команду. Потому сначала рекомендую изучить наш урок по использованию командной строки. Настройки php задаются в файле php.ini, который в linux лежит в /etc/php/, а в Windows - в папке с PHP, но нам пока не требуется их менять.
Проверь, что ты смог правильно установить PHP. Для этого набери команду
Если все верно, то она выведет информацию о версии установленного интерпретатора PHP (если у тебя PHP не находится в PATH , то вместо php придется писать полный путь к файлу, например c:\php\php.exe ). Еще одна полезная команда - это php -i - она выводит информацию о текущих настройках PHP. Все возможные опции, которые можно указать, перечислены в мануале по использованию php.
Встроенный в PHP сервер
В интерпретатор PHP встроен простой веб-сервер. Его не стоит использовать на реальном сайте, но он годится для того, чтобы запускать простые скрипты на своем компьютере.
Инструкции ниже требуют знания командной строки, если ты не знаешь ее, то прочти сначала урок по ней.
Итак, в PHP встроен простейший веб-сервер для разработчиков. Чтобы запустить его, создай папку, из которой будут раздаваться файлы, она называется корень сервера или document root. Допустим, это d:\server. Открой командную строку и перейди в эту папку, а затем запусти веб-сервер, набрав следующие команды. После каждой команды надо нажимать клавишу Enter. Будь внимателен при их наборе, не пропускай пробелы, не путай прямую и обратную наклонную черту:
(если ты работаешь не под Windows, то команды будут иметь немного другой вид). Если тебе лень писать каждый раз эти команды вручную, то в уроке по командной строке описано, как можно поместить их в bat-файл, который можно запускать просто двойным кликом по иконке.
-S обозначает «запуститься в режиме веб-сервера». Надо написать именно заглавную S, c маленькой буквой не заработает. localhost (вместо него можно еще писать 127.0.0.1 - это твой собственный адрес) обозначает принимать соединения только со своего компьютера, и не принимать соединения с других устройств (если хочешь чтобы твой сервер был доступен во всей локальной сети, пиши вместо localhost адрес 0.0.0.0 — после этого к тебе можно будет зайти по ip).
9001 — это номер порта, на котором сервер будет ждать соединения от браузера. Если произойдет ошибка и будет написано что этот порт уже занят, введи другое число (от 1 до 65534), например 9002. Вообще-то обычно для веб-сервера используется порт 80, но у тебя он может быть занят другими программами - например, скайпом, торрентокачалкой или чем-то еще (если это так, стоит зайти в их настройки и запретить его использовать на будущее). Также ты можешь увидеть список занятых портов командой netstat -an , а команда netstat -abn покажет программу, занявшую порт (нужно запускать эту команду из консоли с повышенными привилегиями).
Учти что в линуксе и маке, чтобы открыть порт ниже 1024, нужны права администратора (то есть сервер надо запускать через sudo: sudo php . , что не очень безопасно и не рекомендуется).
Номер порта нужен для того, чтобы на компьютере можно было одновременно запустить несколько работающих с сетью программ. Мы назначаем каждой из них свой номер порта. Когда на компьютер приходят данные из сети, ОС по номеру порта понимает какой именно программе они адресованы. Две программы не могут использовать одновременно один и тот же порт. Подробнее о TCP-портах.
Завершить работу сервера можно, нажав Ctrl + C или закрыв окно консоли. Сервер будет в процессе работы писать в консоль информацию о поступающих от браузера запросах и информацию о возникающих ошибках.
Теперь надо проверить, как работает наш сервер. По умолчанию веб-сервер просто отдает файлы из корневой папки, путь к которым указан в URL. Создай в папке сервера файл, например 1.txt и напиши в нем текст, например hello world (латиницей, чтобы не беспокоиться о кодировках). После этого открой браузер и введи в адресную строку адрес
Если все верно, ты должен увидеть содержимое текстового файла, а в консоли появится строчка с этим запросом. Если что-то не работает - перепроверяй, запущен ли php, что он пишет в консоль, правильно ли ты написал слово localhost и номер порта.
Повторим еще раз, что происходит в этом случае:
- браузер соединяется с веб-сервером на порту 9001
- браузер отправляет запрос на получение файла cat.jpg
- сервер обрабатывает запрос, находит файл и отправляет ответ с кодом 200 , заголовком Content-Type: image/jpg и содержимым файла в теле ответа
- браузер извлекает картинку из тела ответа и отображает на экране
Разумеется, веб-сервер и браузер не обязательно запускать на одном и том же компьютере. Можно запустить веб-сервер на одном компьютере, и делать запрос из браузера с другого компьютера - все будет работать точно так же. Именно это и происходит, когда ты заходишь на какой-то сайт - твой браузер запрашивает и отображает файлы с удаленного компьютера.
Пока мы запрашивали текстовые файлы и картинки, сервер в PHP отдавал их как статические файлы. Но сервер умеет еще генерировать страницы динамически. Если мы запросим PHP-файл, то веб-сервер вместо отдачи этого файла запустит записанный в нем код и отдаст в браузер то, что выводит этот код.
Создадим в корневой папке файл 1.php с таким содержимым:
Обрати внимание, что браузер сам не умеет выполнять PHP-код. Он лишь посылает запрос на сервер и отображает то, что придет в ответ. PHP-код выполняет именно сервер.
Если ты видишь вместо него белую страницу, а исходный код в браузере показывает текст скрипта - значит скрипт не выполнился. Проверь, правильный ли URL в адресной строке браузера. Если там что-то вроде file://d:/server/1.php - значит ты невнимательно прочел инструкции выше. Протокол file:// обозначает, что браузер открывает файл напрямую с диска, а не запрашивает с веб-сервера, и потому PHP-код не будет выполняться.
Если при выполнении скрипта возникают какие-то ошибки, они отображаются в консоли, где запущен сервер. Не забывай туда поглядывать.
Наконец, давай сделаем еще один файл, который показывает текущие настройки PHP и который пригодится нам если что-то пойдет не так. Создай файл info.php с текстом:
И открой через браузер. Ты увидишь большую синюю таблицу - поизучай ее, она пригодится тебе не раз, когда ты будешь разбираться почему что-то не работает.
Передача аргументов в скрипт
Если пользователь не укажет в URL значения x и y , то PHP не поместит их в массив $_GET . Когда наш скрипт попытается обратиться к $_GET['x'] , произойдет ошибка. Потому мы делаем проверку, что в массиве есть такой элемент, и если его нет, то присваиваем переменной значение 0. Если элемент есть, то мы обрабатываем значение функцией floatval, которая преобразует любое значение в целое или дробное число. Даже если пользователь вместо числа напишет бессмысленное значение вроде x=xyz , в программе не произойдет ошибки.
В PHP7 добавили новый оператор объединения с null, с помощью которого можно чуть упростить код:
В этом месте ты можешь достать свои старые задачи, которые ты делал на PHP, и попробовать позапускать их через сервер и браузер.
Разумеется, вручную вписывать аргументы в URL (особенно, если они содержат спецсимволы) не очень удобно. В языке HTML есть возможность помещать на страницу формы с полями ввода, выпадающими списками, чекбоксами и радиокнопками. При заполнении такой формы и нажатии кнопки отправки браузер сам соберет URL с добавлением введенных значений и отправит запрос на сервер.
Пробелы и перевод строки
Чтобы переносы строк нормально работали и в браузере, и при запуске скрипта в консоли, можно использовать для них традиционный \n, а в начале программы поставить
Это заставит браузер воспринимать то, что выводит твоя программа, как обычный текст, а не HTML-код, и уважать переносы строк в нем. Иначе перенос строки будет в исходном коде страницы (его можно увидеть нажав Ctrl + U), но на самой странице его не будет.
Ведь по умолчанию веб-сервер отдает результат в браузер, говоря что это HTML-файл, а в этом языке любое число пробелов и переводов строк выводится как один пробел. Отдавая заголовок Content-Type , мы говорим браузеру что наш файл содержит обычный текст и не должен интерпретироваться как HTML код.
Если ты попытаешься открыть URL, в котором не указано имя файла, например: http://localhost:9001/ , то сервер будет искать файлы с названием index.php или index.html в корневой папке. Это так называемый "индексный" файл, который отдается по умолчанию, если конкретное имя файла не указано.
Имя скрипта маршрутизации надо указать при запуске веб-сервера. Попробуем написать простой скрипт с такой логикой:
- если запрошен URL /latest-news, то выполнить скрипт news.php
- если запрошен URL /hello, то вывести фразу "hello world"
- иначе искать указанный в URL файл
Создадим в корневой папке скрипт router.php с таким кодом. Если ты видишь тут незнакомые функции и команды, погугли их:
Чтобы веб-сервер использовал скрипт маршрутизации, его надо запускать такой командой:
Вот краткое объяснение использованных в скрипте выше конструкций:
Апач сложнее чем встроенный сервер, но дает больше возможностей.
Что делать дальше
Ты наверно заметил, что в тексте выше не раз повторяется слово HTML. Это неспроста - на этом языке верстаются веб-страницы. Иди и изучи основы этого языка, чтобы ты умел сверстать хотя бы страницу с заголовком, картинкой и ссылкой. Это займет у тебя максимум пару дней.
Наконец, стоит почитать туториал в официальном мануале PHP и научиться добавлять в HTML странички PHP код, а также обрабатывать данные из форм:
После этого прочитай урок про шаблоны.
Изучив все это, попробуй решить задачи ниже. Если ты смог их решить - отлично, ты готов к написанию своего первого веб-приложения на PHP - задаче про список студентов.
Полезные функции и конструкции PHP, которые стоит изучить
- require , require_once
- header()
- setcookie()
В файле с запросом должно быть примерно такое содержимое:
При соединении openssl выведет довольно много отладочной информации об используемом сервером сертификате и параметрах SSL/TLS шифрования. Ее вывод можно отключить, дописав к команде (до символа < ) флаг -quiet . Про другие опции можно прочесть в мануале по openssl s_client (англ., сложный).
Еще один кредит
Для решения этой задачи тебе надо изучить основы HTML, HTML-формы и глобальную переменную $_GET в PHP.
Сделай форму с 3 полями ввода: сумма кредита, ежемесячная выплата, комиссия и проценты в месяц. При их заполнении программа должна рассчитать кредит (аналогично задаче про айфон) и вывести один из вариантов:
- надпись "поле X заполнено неверно", если введены неправильные данные
- надпись "выплатить кредит невозможно так как ежемесячный прирост X больше ежемесячной выплаты", если выплатить кредит не получится
- надпись "время выплаты: N месяцев, сумма выплаты: X"
Для решения этой задачи надо изучить основных HTML, HTML-формы и функцию htmlspecialchars() .
Сделай страницу с формой (использующей метод GET) из поля ввода textarea (с именем text) и кнопки отправки. Никакого оформления и CSS не требуется, просто черный текст на белом фоне. При вводе любого текста и нажатия кнопки внизу под textarea должен отобразиться введенные текст и ссылка.
Текст должен точно соответствовать введенному, корректно отображать все символы, включая пробелы и переводы строк (тут тебе поможет тег pre), точно так как их ввел пользователь. Проверь что сочетания вроде
Отображаются ровно в том же виде как введены.
Кроме текста, надо выводить ссылку вида script.php?text=. <=1, которая содержит в параметре text введенный текст, а в параметре lt единицу и открыв которую, мы можем увидеть его на странице.
- про то, как корректно вставить текст с любыми символами в HTML-код, написано в уроке про XSS
- по умолчанию в HTML любое число переводов строк и пробелов воспринимается как один пробел. Чтобы сохранить все пробелы и переводы строк при выводе, нужно либо использовать HTML-тег pre, либо CSS-свойство white-space
- при подстановке параметра в ссылку вроде x.php?a=. необходимо корректно экранировать спецсимволы. Как это сделать, описано в уроке про структуру URL
- при подстановке ссылки в HTML-атрибут href ее, разумеется, тоже нужно корректно экранировать
Для решения этой задачи необходимо изучить куки, переменную $_COOKIE и функцию setcookie() .
Сделай скрипт, запоминающий сколько раз пользователь заходил на страницу и показывающий ему это число: "добро пожаловать - в N-й раз". Для хранения надо использовать куки, чтобы у каждого пользователя был свой счетчик.
Проверь что при открытии окна браузера в анонимном режиме или другого браузера счетчик в нем работает независимо, а при очистке кук сбрасывается в 0.
Всем привет! Сегодня я расскажу вам о том, как с помощью PHP можно работать с Selenium.
Чаще всего это бывает необходимо, когда перед вами стоит задача написать автотесты для web интерфейса или свой парсер/краулер.
«Selenium — это инструмент для автоматизации действий веб-браузера.
В большинстве случаев используется для тестирования Web-приложений, но этим не
ограничивается. В частности, реализация Selenium WebDriver для браузера phantomjs
часто используется как веб-граббер.»
Мы рассмотрим следующие нюансы:
- Использование Behat/Mink для соединения с Selenium
- Запуск Selenium в docker, и удаленный доступ по VNC
- Расширим функционал Behat с помощью Extension Feature
1. Готовим Behat и Mink
Behat это php фреймворк, который изначально был создан для поведенческого тестирования (BDD). Он является официальной PHP реализацией более известного продукта Cucumber, который часто используется в других языках программирования.
Сам по себе работать с Selenium он не умеет и предназначен больше для написания функциональных тестов без использования браузера.
Устанавливается как обычный пакет:
Чтобы научить behat работать с браузером, нам понадобится его расширение Mink, а также бридж для работы с конкретным вендором (в нашем случае это Selenium). Полный список вендоров вы сможете найти на страничке Mink. С учетом версий, ваш composer.json должен выглядеть примерно так:
После установки у вас появится vendor/bin/behat файл, ответственный за запуск тестов. Если vendor/bin/behat --version показало вам установленную версию, то с высокой долей вероятности установка прошла успешно :)
Завершающей фазой является конфигурация
Файлы сценариев или (*.feature файлы) — yml файлы, написанные на псевдо-языке Gherkin, содержат, по сути, набор пошаговых инструкций, которые выполнит ваш браузер в ходе исполнения конкретного сьюта. Подробнее о синтаксисе вы можете узнать, перейдя по ссылке выше.
Каждая такая «инструкция» в свою очередь матчится на методы класса «контекста» с помощью регулярных выражений, указанных в аннотациях класса. Behat\MinkExtension\Context\MinkContext
Имена самих методов роли не играют, хотя хорошим тоном будет придерживаться аналогичного аннотациям именования в CamelCase.
Если вам не хватает доступных по умолчанию конструкций Gherkin, вы можете расширить функционал в классах наследниках MinkContext правильно указав аннотации. Эту роль и выполняют «контекстные» классы.
2. Установка и настройка окружения
Те из вас, кто уже работал с Selenium знают, что после старта теста, на машине запустится браузер и пройдет шаги, указанные в .feature файле.
Запуск Selenium в Docker немного сложнее. Во-первых вам понадобятся Иксы в контейнере, во-вторых – вам захочется увидеть, что же происходит внутри контейнера.
Ребята из Selenium уже обо всём позаботились и собирать свой контейнер вам не придется. Контейнер со Standalone сервером на борту будет сразу доступен по 5900 порту, куда можно постучаться с любого VNC клиента (например с этого). Внутри контейнера вас встретит приветливый интерфейс Fluxbox с предустановленным Chrome. В моем случае это выглядит так:
Чтобы прийти к успеху, вы можете запустить докер контейнер, согласно инструкции на сайте:
Важный момент, без шаред волюма /dev/shm хрому не хватит памяти и он не сможет запуститься, поэтому не забываем его указать.
В моем случае используется docker-compose, и YAML файл будет выглядеть следующим образом:
Я хочу, чтобы мои тесты заходили на Facebook через VPN, включенный на хост-машине, поэтому важно указать network_mode.
Чтобы запустить контейнер, используя compose, выполним следующую команду:
Теперь пробуем подсоединиться по VNC на localhost:5900 и открыть браузер внутри контейнера. Если вам это удалось и вы видите что-то похожее на скриншот выше — вы прошли этот уровень.
3. От теории к практике. Автоматизируем
В примере, приведенном ниже, я буду доставать всех пользователей Facebook по переданным фамилии и имени. Сценарий будет выглядеть следующим образом:
И соответственно Context класс (констуктор и нэймспейсы опущены)
В методе SearchExntesion::load пробрасывается Сервис SearchController, отвечающий непосредственно за объявление параметров и их прием/обработку.
Если всё объявлено правильно, то список доступных команд behat дополнится новым аргументом --search-by-fullname:
Получив входные данные внутри SearchController, они могут быть переданы в Context классы напрямую, либо сохранены в базе данных и т.д В примере выше я для этого использую Registry паттерн. Подход вполне рабочий, но если вы знаете, как это сделать по-другому, пожалуйста, расскажите в комментариях.
У меня есть для вас непростое задание. Когда в следующий раз начнёте новый проект, постарайтесь обойтись без PHP-фреймворка. Я не собираюсь перечислять недостатки фреймворков, и это не проявление синдрома неприятия чужой разработки: в этом руководстве мы будем использовать пакеты, написанные разработчиками нескольких фреймворков. Я всецело уважаю инновации в этой сфере.
Но эта статья не о них. Она о вас. О возможности стать лучше как разработчик.
Возможно, главным плюсом отказа от фреймворка станет знание, как всё работает под капотом. Вы будете видеть, что происходит, не полагаясь на фреймворк, который заботится о вас настолько, что вы не можете что-то отладить или до конца понять.
Возможно, ваша следующая работа не позволит вам насладиться запуском нового проекта без фреймворка. Многие важные, критические для бизнеса PHP-задачи подразумевают использование уже существующих приложений. И неважно, будет это приложение, построенное на современном фреймворке вроде Laravel или Symfony, на одной из старых платформ вроде CodeIgniter или FuelPHP — либо это удручающе широко распространённое легаси PHP-приложение с «include-oriented архитектурой»: если сейчас вы будете разрабатывать без фреймворка, то окажетесь лучше подготовлены к любому будущему PHP-проекту.
Но сегодня благодаря стараниям PHP-FIG в сфере автозагрузки и взаимной совместимости вы можете разрабатывать без фреймворка, не создавая его попутно. Существует множество замечательных, взаимно совместимых пакетов, написанных многочисленными разработчиками. И собрать их в единую систему гораздо проще, чем вы думаете!
Как работает PHP?
Прежде всего важно понять, как PHP-приложения взаимодействуют с внешним миром.
PHP исполняет серверные приложения в цикле запрос/ответ. Всё взаимодействие с приложением — из браузера, командной строки или REST API — приходит в него в качестве запросов. При получении запроса приложение загружается, обрабатывает запрос и генерирует ответ, который передаётся обратно клиенту, а приложение закрывается. И так происходит при каждом обращении.
Контроллер запросов
Вооружившись этим знанием, начнём с фронт-контроллера. Он представляет собой PHP-файл, обрабатывающий все запросы к вашему приложению. То есть это первый PHP-файл, в который попадает запрос, и (по сути) последний PHP-файл, через который проходит ответ приложения.
Давайте воспользуемся классическим примером с Hello, world!, обслуживаемым встроенным в PHP веб-сервером, чтобы проверить, всё ли настроено корректно. Если вы этого ещё не сделали, то удостоверьтесь, что в среде установлен PHP 7.1 или выше.
Создадим директорию проекта, в ней сделаем вложенную директорию public , а внутри неё — файл index.php с таким кодом:
Обратите внимание, здесь мы объявляем строгую типизацию — это нужно делать в начале каждого PHP-файла вашего приложения, — потому что подсказки типов (type hinting) важны для отладки и ясного понимания теми, кто будет заниматься кодом после вас.
Далее с помощью инструмента командной строки (вроде Terminal на MacOS) перейдём в директорию проекта и запустим встроенный в PHP веб-сервер.
Отлично. Переходим к следующему шагу!
Автозагрузка и сторонние пакеты
Когда вы впервые начали работать с PHP, то, вероятно, использовали выражения include или require для получения функциональности или конфигураций из других PHP-файлов. В целом этого лучше избегать, потому что другим людям потом будет гораздо труднее разобраться в коде и понять, где находятся зависимости. Это превращает отладку в кошмар.
Выход — автозагрузка. Это означает, что, когда вашему приложению нужно использовать какой-то класс, PHP знает, где его найти, и автоматически загружает в момент вызова. Эта возможность существует со времён PHP 5, но стала активно применяться только с появлением PSR-0 (стандарта автозагрузки, сегодня заменён PSR-4).
Можно было бы пройти через тягомотину написания собственного автозагрузчика, но раз мы выбрали Composer для управления сторонними зависимостями, а в нём уже есть очень удобный автозагрузчик, то его мы и будем использовать.
Проверьте, что у вас установлен Composer. Затем настройте его для своего проекта.
После этого пройдите через интерактивное руководство по генерированию конфигурационного файла composer.json . Затем откройте его в редакторе и добавьте поле autoload , чтобы получилось так, как показано ниже (тогда автозагрузчик будет знать, где искать ваши классы).
Теперь установите для этого проекта Composer, которые подтянет все зависимости (если они уже есть) и настроит для нас автозагрузчик.
Обновите public/index.php для запуска автозагрузчика. В идеале это одно из нескольких выражений include, которые вы используете в приложении.
Если перезагрузить приложение в браузере, вы не увидите никакой разницы. Однако автозагрузчик работает, просто он не делает ничего тяжёлого. Давайте перенесём пример с Hello, world! в автоматически загружаемый класс, чтобы проверить, как всё работает.
В корне проекта создадим папку src и вставим в неё файл HelloWorld.php с таким кодом:
Теперь в public/index.php замените выражение echo вызовом метода announce в классе HelloWorld .
Что такое внедрение зависимостей?
Внедрение зависимостей — это методика, при которой каждая зависимость предоставляется объекту, которому она требуется, вместо того чтобы объект обращался наружу за получением какой-то информации или функциональности.
Допустим, методу класса нужно считать из базы данных. Для этого надо к ней подключиться. Обычно новое подключение создаётся с учётными данными, полученными из глобального пространства.
Но это не лучшее решение. На чуждый метод возлагается ответственность за создание объекта нового подключения к БД, получения учётных данных и обработки любых проблем в случае сбоя подключения. В результате в приложении дублируется масса кода. А если вы попытаетесь прогнать этот класс через модульное тестирование, то не сможете. Класс тесно взаимосвязан со средой приложения и базой данных.
Давайте с самого начала не будем усложнять работу с тем, что требуется классу. Просто в первую очередь потребуем, чтобы объект PDO был внедрён в класс.
Получилось гораздо чище и проще для понимания, меньше вероятность ошибок. Благодаря подсказке типов и внедрению зависимостей метод объявляет именно то, что ему нужно для выполнения задачи, и получает необходимое без вызова из себя внешней зависимости. А когда речь пойдёт о модульном тестировании, мы окажемся готовы к моделированию подключения к БД и спокойно пройдём тест.
Контейнер внедрения зависимости — это инструмент, в который вы обёртываете всё ваше приложение ради создания и внедрения этих самых зависимостей. Контейнер не является необходимым, но значительно облегчает жизнь по мере роста и усложнения вашего приложения.
Мы воспользуемся самым популярным DI-контейнером для PHP с изобретательным названием PHP-DI. (Надо отметить, что в его документации внедрение зависимостей описано иначе, и кому-то так будет понятнее.)
Контейнер внедрения зависимостей
Поскольку мы настроили Composer, установка PHP-DI пройдёт практически безболезненно. Для этого снова обратимся к командной строке:
Обновите public/index.php для конфигурирования и сборки контейнера.
Ничего особенного пока не произошло. Это лишь простой пример, где всё необходимое помещено в один файл для удобства наблюдения.
Мы конфигурируем контейнер, поэтому нужно явно объявить зависимости (а не использовать автоматическое внедрение или аннотации) и извлечь из контейнера объект HelloWorld .
Заметка на полях: автоматическое внедрение зависимостей может быть полезной фичей в начале создания приложения, но в дальнейшем оно усложняет сопровождение, поскольку зависимости остаются относительно скрытыми. К тому же возможно, что через несколько лет другой разработчик подключит какую-нибудь библиотеку, и в результате несколько библиотек будут реализовывать один интерфейс. Это сломает автоматическое внедрение зависимостей и приведёт к непредсказуемому потоку багов. Разработчик, внёсший изменение, может их вообще не заметить.
Давайте ещё больше всё упростим, импортировав пространства имён там, где это возможно.
Пока что выглядит всё так, словно мы устроили суматоху ради выполнения того, что уже делали раньше.
Не беспокойтесь, контейнер нам пригодится, когда добавим несколько других инструментов, помогающих передавать запросы напрямую через приложение. Эти инструменты будут использовать контейнер для загрузки правильных классов по мере необходимости.
Middleware
Если представить приложение в виде луковицы, в которой запросы идут снаружи к центру, а ответы в обратном направлении, то middleware — это каждый слой луковицы, который получает запросы, вероятно, что-то делает с ответами и передаёт их в нижний слой либо генерирует ответ и отправляет в верхний слой. Такое случается, если промежуточный слой проверяет запросы на соответствие каким-то условиям вроде запроса несуществующего пути.
Если запрос проходит до конца, приложение обработает его и превратит в ответ. После этого каждый промежуточный слой в обратном порядке будет получать ответ, возможно, модифицировать его и передавать следующему слою.
Варианты использования промежуточных слоев:
- Отладка проблем при разработке.
- Постепенная обработка исключений в production.
- Ограничение частоты входящих запросов.
- Ответы на запросы неподдерживаемых медиатипов.
- Обработка CORS.
- Маршрутизация запросов в соответствующие обрабатывающие классы.
Промежуточный слой — это единственный способ реализации инструментов для обработки всех этих ситуаций? Вовсе нет. Но реализации middleware позволяют сделать цикл запрос/ответ гораздо понятнее, что сильно упростит отладку и ускорит разработку.
Мы воспользуемся промежуточным слоем для последнего сценария: маршрутизации.
Маршрутизация
Маршрутизатор применяет информацию из запроса, чтобы понять, какой класс должен его обработать (например, URI /products/purple-dress/medium должен быть обработан с помощью класса ProductDetails::class с передаваемыми в качестве аргументов purple-dress и medium ).
Наше приложение будет использовать популярный маршрутизатор FastRoute через реализацию промежуточного слоя, совместимого с PSR-15.
Диспетчер middleware
Чтобы наше приложение стало работать с каким-либо промежуточным слоем, нам понадобится диспетчер.
PSR-15 — это стандарт, определяющий интерфейсы для middleware и диспетчеров (в спецификации они называются «обработчики запросов»), обеспечивающий взаимосовместимость широкого спектра решений. Нам лишь нужно выбрать диспетчер, совместимый с PSR-15, и он будет работать с любым совместимым middleware.
В качестве диспетчера установим Relay.
Подготовим Relay к приёму промежуточных слоев.
В строке 16 мы с помощью ServerRequestFactory::fromGlobals() будем собирать всю информацию, необходимую для создания нового запроса и передачи его Relay . Здесь запрос попадает в стек промежуточных слоев.
Теперь добавим FastRoute и обработчика запросов ( FastRoute определяет, валиден ли запрос и может ли он быть обработан нашим приложением, а обработчик запросов передаёт запрос тому обработчику, что сконфигурирован для этого маршрута).
А теперь определим маршрут для класса обработчика Hello, world. Здесь мы воспользуемся маршрутом /hello , чтобы продемонстрировать возможность использования маршрута, отличающегося от базового URI.
Чтобы всё заработало, нужно обновить HelloWorld , сделав его вызываемым классом, то есть чтобы этот класс можно было вызвать как функцию.
Обратите внимание на добавленный exit; в магическом методе __invoke() . Скоро вы поймёте, к чему это.
Клей, который всё скрепляет вместе
Проницательный читатель заметит, что DI-контейнер, несмотря на все трудности его конфигурирования и сборки, на самом деле ничего не делает. Диспетчер и промежуточное ПО могут работать и без контейнера.
Так зачем он нужен?
А что, если — как это почти всегда бывает в реальных приложениях — у класса HelloWorld есть зависимость?
Давайте её добавим и посмотрим, что произойдёт.
Перезагрузим браузер, и.
Это происходит потому, что для функционирования HelloWorld требуется при его создании внедрить строковое значение, а у нас это повисло в воздухе. И здесь на помощь приходит контейнер.
Давайте определим зависимость в контейнере и передадим его в RequestHandler для разрешения.
Вуаля! При перезагрузке браузера вы должны увидеть Hello, bar world!.
Помните, я упомянул о выражении exit в HelloWorld ?
Это простой способ удостовериться, что мы получили простой ответ, но всё же это не лучший способ отправки выходных данных в браузер. Такой грубый подход заставляет HelloWorld делать лишнюю работу по отдаче отчетов — а этим должен заниматься другой класс, — что слишком усложняет отправку заголовков и кодов статуса, а также приводит к закрытию приложения, не давая шансов запуститься промежуточному ПО, идущему после HelloWorld .
Обновим HelloWorld для возвращения Response .
Обновим определение контейнера, чтоб HelloWorld предоставлялся со свежим объектом Response .
Если мы сейчас обновим страницу, то получим пустой экран. Приложение возвращает из диспетчера промежуточных слоев правильный объект Response , а потом… что?
Просто ничего с ним не делает.
Нам нужен ещё один инструмент: эмиттер. Он находится между приложением и веб-сервером (Apache, nginx и т. д.) и отправляет ваш ответ клиенту, сгенерировавшему запрос. Эмиттер просто берёт объект Response и преобразует в инструкции, доступные для понимания серверным API.
Для простоты примера мы используем здесь очень простой эмиттер. Хотя он может быть гораздо сложнее, но в случае больших загрузок реальное приложение должно быть сконфигурировано для автоматического использования потокового эмиттера. Это хорошо описано в блоге Zend.
Обновим public/index.php для получения Response от диспетчера и передачи в эмиттер.
В строке 15 заканчивается цикл запрос/ответ и вступает в работу веб-сервер.
Завершение
Мы углубились в некоторые технологии и аргументацию, но я надеюсь, вам очевидна простота программы начальной загрузки нового приложения без сопутствующего хлама фреймворка. Также надеюсь, что вы теперь лучше готовы к применению этих технологий в существующих приложениях.
Использованное в статье приложение лежит в репозитории, можете свободно форкать и скачивать.
Приветствую, уважаемое сообщество.
Прежде всего, хочу поблагодарить за очень полезный ресурс. Не раз находил здесь множество интересных идей и практических советов.
Цель этой статьи — осветить подводные камни использования сессий в PHP. Конечно, есть документация по PHP и масса примеров, и данная статья не претендует на полное руководство. Она призвана раскрыть некоторые ньюансы работы с сессиями и оградить разработчиков от ненужной траты времени.
Самым распространенным примером использования сессий является, конечно, авторизация пользователей. Начнем с самой базовой реализации, чтобы последовательно развивать ее по мере появления новых задач.
(В целях экономии места и времени ограничимся в примерах только самими функциями работы с сессиями, вместо того, чтобы строить здесь полноценное тестовое приложение с красивой иерархией классов, исчерпывающей обработкой ошибок и прочими правильными штуками).
Примечание: Подразумевается, что базовые знания о сессиях PHP у читателя имеются, поэтому принцип работы функций session_start() и session_destroy() освещать здесь не будем. Задачи верстки формы входа и аутентификации пользователя не относятся к теме статьи, поэтому их мы также опустим. Напомню только, что для идентификации пользователя в каждом последующем запросе, нам необходимо в момент успешного входа сохранить в сессионной переменной (с именем userid, например) идентификатор пользователя, который будет доступен во всех последующих запросах в пределах жизни сессии. Также необходимо реализовать обработку результата нашей функции startSession(). Если функция вернула FALSE — отобразить в браузере форму входа. Если функция вернула TRUE, и сессионная переменная, содержащая идентификатор авторизованного пользователя (в нашем случае — userid), существует — отобразить страницу авторизованного пользователя (подробнее об обработке ошибок см. дополнение от 2013-06-07 в разделе о сессионных переменных).
Пока все понятно. Вопросы начинаются, когда требуется реализовать контроль отсутствия активности пользователя (session timeout), дать возможность одновременной работы в одном браузере нескольких пользователей, а также защитить сессии от несанкционированного использования. Об этом и пойдет речь ниже.
Контроль отсутствия активности пользователя встроенными средствами PHP
Первый вопрос, который часто возникает у разработчиков всевозможных консолей для пользователей — автоматическое завершение сеанса в случае отсутствия активности со стороны пользователя. Нет ничего проще, чем сделать это с помощью встроенных возможностей PHP. (Этот вариант не отличается особой надежностью и гибкостью, но рассмотрим его для полноты картины).
Немного пояснений. Как известно, PHP определяет, какую именно сессию нужно запустить, по имени куки, передаваемом браузером в заголовке запроса. Браузер же, в свою очередь, получает этот куки от сервера, куда помещает его функция session_start(). Если время жизни куки в браузере истекло, он не будет передан в запросе, а значит PHP не сможет определить, какую сессию нужно запустить, и расценит это как создание новой сессии. Параметр настроек PHP session.gc_maxlifetime, который устанавливается равным нашему таймауту отсутствия активности пользователя, задает время жизни PHP-сессии и контролируется сервером. Работает контроль времени жизни сессии следующим образом (здесь рассматривается пример хранилища сессий во временных файлах как самый распространенный и установленный по умолчанию в PHP вариант).
В момент создания новой сессии в каталоге, установленном как каталог для хранения сессий в параметре настроек PHP session.save_path, создается файл с именем sess_, где — идентификатор сессии. Далее, в каждом запросе, в момент запуска уже существующей сессии, PHP обновляет время модификации этого файла. Таким образом, в каждом следующем запросе PHP, путем разницы между текущим временем и временем последней модификации файла сессии, может определить, является ли сессия активной, или ее время жизни уже истекло. (Механизм удаления старых файлов сессий более подробно рассматривается в следующем разделе).
Примечание: Здесь следует отметить, что параметр session.gc_maxlifetime действует на все сессии в пределах одного сервера (точнее, в пределах одного главного процесса PHP). На практике это значит, что если на сервере работает несколько сайтов, и каждый из них имеет собственный таймаут отсутствия активности пользователей, то установка этого параметра на одном из сайтов приведет к его установке и для других сайтов. То же касается и shared-хостинга. Для избежания подобной ситуации используются отдельные каталоги сессий для каждого сайта в пределах одного сервера. Установка пути к каталогу сессий производится с помощью параметра session.save_path в файле настроек php.ini, или путем вызова функции ini_set(). После этого сессии каждого сайта будут храниться в отдельных каталогах, и параметр session.gc_maxlifetime, установленный на одном из сайтов, будет действовать только на его сессии. Мы не станем рассматривать этот случай подробно, тем более, что у нас в запасе есть более гибкий вариант контроля отсутствия активности пользователя.
Контроль отсутствия активности пользователя с помощью сессионных переменных
Казалось бы, предыдущий вариант при всей своей простоте (всего пару дополнительных строк кода) дает все, что нам нужно. Но что, если не каждый запрос можно расценивать как результат активности пользователя? Например, на странице установлен таймер, который периодически выполняет AJAX-запрос на получение обновлений от сервера. Такой запрос нельзя расценивать как активность пользователя, а значит автоматическое продление времени жизни сессии является не корректным в данном случае. Но мы знаем, что PHP обновляет время модификации файла сессии автоматически при каждом вызове функции session_start(), а значит любой запрос приведет к продлению времени жизни сессии, и таймаут отсутствия активности пользователя не наступит никогда. К тому же, последнее примечание из предыдущего раздела о тонкостях работы параметра session.gc_maxlifetime может показаться кому-то слишком запутанным и сложным в реализации.
Для решения этой проблемы откажемся от использования встроенных механизмов PHP и введем несколько новых сессионных переменных, которые позволят нам контролировать время отсутствия активности пользователей самостоятельно.
Подытожим. В каждом запросе мы проверяем, не достигнут ли таймаут с момента последней активности пользователя до текущего момента, и если он достигнут — уничтожаем сессию и прерываем выполнение функции, возвращая FALSE. Если же таймаут не достигнут, и в функцию передан параметр $isUserActivity со значением TRUE — обновляем время последней активности пользователя. Все, что нам остается сделать — это определять в вызывающем скрипте, является ли запрос результатом активности пользователя, и если нет — вызывать функцию startSession со значением параметра $isUserActivity, равным FALSE.
Обработка результата функции sessionStart()
В комментариях обратили внимание на то, что возврат FALSE не дает полного понимания причины ошибки, и это абсолютно справедливо. Я не стал публиковать здесь подробную обработку ошибок (объем статьи и так не маленький), поскольку это не относится напрямую к теме статьи. Но учитывая комментарии, внесу ясность.
Теперь, даже если сессия на сервере по-прежнему существует, она будет уничтожена при первом же обращении к ней, если таймаут отсутствия активности пользователя истек. И это произойдет независимо от того, какое время жизни сессий установлено в глобальных настройках PHP.
Примечание: А что произойдет, если браузер был закрыт, и куки с именем сессии был автоматически уничтожен? Запрос к серверу при следующем открытии браузера не будет содержать куки сессии, и сервер не сможет открыть сессию и проверить таймаут отсутствия активности пользователя. Для нас это равносильно созданию новой сессии и никак не влияет на функционал и безопасность. Но возникает справедливый вопрос — а кто же тогда уничтожит старую сессию, если до сих пор ее уничтожали мы по истечении таймаута? Или она теперь будет висеть в каталоге сессий вечно? Для очистки старых сессий в PHP существует механизм под названием garbage collection. Он запускается в момент очередного запроса к серверу и чистит все старые сессии на основании даты последнего изменения файлов сессий. Но запуск механизма garbage collection происходит не при каждом запросе к серверу. Частота (а точнее, вероятность) запуска определяется двумя параметрами настроек session.gc_probability и session.gc_divisor. Результат от деления первого параметра на второй и есть вероятностью запуска механизма garbage collection. Таким образом, для того, чтобы механизм очистки сессий запускался при каждом запросе к севреру, эти параметры нужно установить в равные значения, например «1». Такой подход гарантирует чистоту каталога сессий, но, очевидно, является слишком накладным для сервера. Поэтому в production-системах по умолчанию устанавливается значение session.gc_divisor, равное 1000, что означает, что механизм garbage collection будет запускаться с вероятностью 1/1000. Если вы поэкспериментируете с этими настройками в своем файле php.ini, то сможете заметить, что в описанном выше случае, когда браузер закрывается и очищает все свои куки, в каталоге сессий какое-то время все еще остаются старые сессии. Но это не должно вас волновать, т.к. как уже было сказано, это ни коим образом не влияет на безопасность нашего механизма.
Предотвращение зависания скриптов из-за блокировки файла сессии
В комментариях подняли вопрос о зависании одновременно выполняющихся скриптов из-за блокировки файла сессии (как самый яркий вариант — long poll).
Для начала отмечу, что эта проблема напрямую не зависит от загруженности сервера или количества пользователей. Конечно, чем больше запросов, тем медленнее выполняются скрипты. Но это коссвенная зависимость. Проблема появляется только в пределах одной сессии, когда серверу приходит несколько запросов от имени одного пользователя (например, один из них long poll, а остальные — обычные запросы). Каждый запрос пытается получить доступ к одному и тому же файлу сессии, и если предыдущий запрос не разблокировал файл, то последующий будет висеть в ожидании.
Для сведения блокировки файлов сессий к минимуму настоятельно рекомендуется закрывать сессию путем вызова функции session_write_close() сразу после того, как выполнены все действия с сессионными переменными. На практике это означает, что не следует хранить в сессионных переменных все подряд и обращаться к ним на всем протяжении выполнения скрипта. А если и надо хранить в сессионных переменных какие-то рабочие данные, то считывать их сразу при старте сессии, сохранять в локальные переменные для последующего использования и закрывать сессию (имеется ввиду закрытие сессии с помощью функции session_write_close, а не уничтожение с помощью session_destroy).
В нашем примере это означает, что сразу после открытия сессии, проверки времени ее жизни и существования авторизованного пользователя, мы должны считать и сохранить все дополнительные необходимые приложению сессионные переменные (если такие существуют), после чего закрыть сессию с помощью вызова session_write_close() и продолжить выполнение скрипта, будь то long poll или обычный запрос.
Защита сессий от несанкционированного использования
Представим себе ситуацию. Один из ваших пользователей цепляет троян, который грабит куки браузера (в котором хранится наша сессия) и отправляет его на указанный email. Злоумышленник получает куки и использует его для подделки запроса от имени нашего авторизованного пользователя. Сервер успешно принимает и обрабатывает этот запрос, как если бы он пришел от авторизованного пользователя. Если не реализована дополнительная проверка IP-адреса, такая атака приведет к успешному взлому аккаунта пользователя со всеми вытекающими последствиями.
Почему это стало возможным? Очевидно, потому что имя и идентификатор сессии всегда одни и те же на все время жизни сессии, и если получить эти данные, то можно беспрепятственно слать запросы от имени другого пользователя (естественно, в пределах времени жизни этой сессии). Возможно, это не самый распространенный вид атак, но теоретически все выглядит вполне реализуемым, особенно учитывая, что подобному трояну даже не нужны права администратора, чтобы грабить куки браузера пользователя.
Как же можно защититься от атак подобного рода? Опять-таки, очевидно, ограничив время жизни идентификатора сессии и периодически изменяя идентификатор в пределах одной сессии. Мы можем также изменять и имя сессии, полностью удаляя старую и создавая новую сессию, копируя в нее все сессионные переменные из старой. Но на суть подхода это не влияет, поэтому для простоты ограничимся только идентификатором сессии.
Понятно, что чем меньше время жизни идентификатора сессии, тем меньше будет времени у злоумышленника, чтобы получить и применить куки для подделки запроса пользователя. В идеальном случае для каждого запроса должен использоваться новый идентификатор, что позволит свести к минимуму возможность использования чужой сессии. Но мы рассмотрим общий случай, когда время регенерации идентификатора сессии устанавливается произвольно.
(Опустим ту часть кода, которая уже рассмотрена).
Итак, при создании новой сессии (которое происходит в момент успешного входа пользователя), мы устанавливаем сессионную переменную starttime, хранящую для нас время последней генерации идентификатора сессии, в значение, равное текущему времени сервера. Далее в каждом запросе мы проверяем, не прошло ли достаточно времени (idLifetime) с момента последней генерации идентификатора, и если прошло — генерируем новый. Таким образом, если в течение установленного времени жизни идентификатора злоумышленник, получивший куки авторизованного пользователя, не успеет им воспользоваться, поддельный запрос будет расценен сервером как неавторизованный, и злоумышленник попадет на страницу входа.
Примечание: Новый идентификатор сессии попадает в куки браузера при вызове функции session_regenerate_id(), которая отправляет новый куки, аналогично функции session_start(), поэтому нам нет необходимости обновлять куки самостоятельно.
Если мы хотим максимально обезопасить наши сессии, достаточно установить время жизни идентификатора в единицу или же вообще вынести функцию session_regenerate_id() за скобки и убрать все проверки, что приведет к регенерации идентификатора в каждом запросе. (Я не проверял влияние такого подхода на быстродействие, и могу только сказать, что функция session_regenerate_id(true) выполняет по сути всего 4 действия: генерация нового идентификатора, создание заголовка с куки сессии, удаление старого и создание нового файла сессии).
Лирическое отступление: Если троян окажется настолько умным, что не будет отправлять куки злоумышленнику, а сам организует отправку заранее подготовленного поддельного запроса сразу при получении куки, описанный выше метод, скорее всего, не сможет защитить от подобной атаки, потому что между временем получения трояном куки и отправкой поддельного запроса практически не будет разницы, и велика вероятность, что в этот момент не произойдет регенерации идентификатора сессии.
Возможность одновременной работы в одном браузере от имени нескольких пользователей
Последняя задача, которую хотелось бы рассмотреть — возможность одновременной работы в одном браузере нескольких пользователей. Эта возможность особенно полезна на этапе тестирования, когда нужно эмулировать одновременную работу пользователей, и желательно делать это в своем любимом браузере, а не использовать весь доступный арсенал или открывать несколько экземпляров браузера в режиме «инкогнито».
В наших предыдущих примерах мы не задавали явно имя сессии, поэтому использовалось имя, установленное в PHP по умолчанию (PHPSESSID). Это значит, что все сессии, которые создавались нами до сих пор, отправляли браузеру куки под именем PHPSESSID. Очевидно, что если имя куки всегда одинаковое, то нет возможности в пределах одного браузера организовать две сессии с одинаковым именем. Но если бы мы для каждого пользователя использовали собственное имя сессии, то проблема была бы решена. Так и сделаем.
Теперь осталось позаботиться о том, чтобы вызывающий скрипт передавал в функцию startSession() уникальный префикс для каждого пользователя. Это можно сделать, например, через передачу префикса в GET/POST параметрах каждого запроса или через дополнительный куки.
Заключение
В заключение приведу полный конечный код наших функций для работы с сессиями PHP, включающий все рассмотренные выше задачи.
Надеюсь, эта статья сэкономит немного времени тем, кто никогда особо не углублялся в механизм сессий, и даст достаточно понимания этого механизма тем, кто только начинает знакомиться с PHP.
Читайте также: