Меню

Настройка session php ini

Настройка времени сессий в PHP

Существуют разные способы установки времени жизни сессий. Попробуем разобраться на примере операционной системы Linux.

Как узнать время жизни сессии

Перед настройкой, стоит посмотреть текущее состояние. Есть несколько методов это сделать:

1. На сервере командой php

Получаем список параметров, имеющих отношение к сессиям. Нас интересуют:

Данные значения — значение по умолчанию. cookie_lifetime => 0 говорит о действии файлов куки до закрытия браузера, если задать этому параметру определенное значение, сессия будет прерываться при активном сеансе, поэтому лучше ее оставлять в значении ноль.

2. C помощью php-функции ini_get

Настройка сессий на веб-сервере

Выполняется путем настройки файла php.ini. Данный способ удобен, если мы являемся администратором веб-сервера, а также если есть гарантия, что общая настройка сессий не повлияет на работоспособность всех веб-приложений, работающих на данном сервере.

Открываем на редактирование php.ini:

И редактируем следующие параметры:

session.gc_maxlifetime = 86400
session.cookie_lifetime = 0

* где параметр gc_maxlifetime указывает на временя в секундах, после прошествии которого данные могут быть удалены; cookie_lifetime — время жизни файлов cookies; 86400 — 24 часа в секундах.
* если параметру gc_maxlifetime задать значение 0, действие сессий будет бесконечным. Это, как правило, не стоит делать — приведет к падению производительности и безопасности сервера.

После настройки параметров, необходимо перезагрузить сервер, являющийся интерпретатором PHP.

systemctl restart apache2 || systemctl restart httpd

* в версиях Linux без systemd используем команду service apache2 restart или service httpd restart.

Если используем FastCGI (PHP-FPM):

systemctl restart php-fpm || service php-fpm restart

Данный файл позволяет веб-мастеру управлять некоторыми настройками веб-сервера. Для его редактирования нужен доступ к файлам сайта. Способ не сработает, если в качестве обработчика PHP используется не Apache, а, например, NGINX + PHP-FPM. Хотя, тут тоже есть способ (о нем будет ниже).

php_value session.gc_maxlifetime 86400
php_value session.cookie_lifetime 0

* как можно заметить, параметры те же, что при настройки через php.ini.

Как говорилось выше, метод не сработает, если не используется Apache. Однако настройку можно выполнить на сервере (опять же, у нас должен быть соответствующий доступ).

Открываем файл настройки веб-сервера, например, в php-fpm:

php_value[session.gc_maxlifetime] = 86400
php_value[session.cookie_lifetime] = 0

После перезапускаем сервис:

systemctl restart php-fpm || service php-fpm restart

Задание параметра в коде приложения

Способ может быть полезен, когда разные страницы портала должны иметь разное время жизни сессии. Для этого можно воспользоваться PHP-функциями ini_set и session_set_cookie_params, например:

Функции обязательно вызывать до открытия сесии (session_start).

Установка сессии в приложении

Некоторые приложения могут переопределять настройки. В таком случае, задать время жизни сессии необходимо в параметрах программы. У каждого приложения свои настройки, в которых необходимо самостоятельно разобраться. Приведем для примера настройку сессии в CMS Битрикс.

Как автоматически продлевать сессии

Если сессия выдается на определенный период и заканчивается в определенное время, это может привести к прерыванию активного сеанса пользователя. Гораздо удобнее, если время действия сессии будет автоматически продлеваться, если посетитель обновляет страницу. Для этого существует параметр cookie_lifetime, который во всех примерах выше мы задавали в значении 0.

Если мы зададим значение cookie_lifetime 86400, то через 24 часа сессия прервется. Это не всегда удобно.

Если есть необходимость в контроле и прерывании сессии, можно воспользоваться php-функцией session_destroy().

Путь хранения файлов сессий

Место хранения файлов сессий задается параметром session.save_path также, так время жизни. По умолчанию, может использоваться путь /var/lib/php/sessions.

Это важный параметр — если у веб-сервера будут отсутствовать права на запись в данный каталог, это приведет к невозможности хранить сессии, что вызовет неожиданные результаты работы приложений.

Источник

Настройка session php ini

Предоставляя INI-настройки, связанные с сессиями, вы можете улучшить безопасность сессий. Некоторые важные настройки безопасности не имеют рекомендованных значений. Вы сами ответственны за выбор необходимых значений.

0 имеет особое значение. Он сообщает браузеру не сохранять cookie в постоянное хранилище. Следовательно, когда браузер закрывается, сессионные cookie сразу же удаляются. Если задать значение отличное от 0, это может позволить другим пользователям использовать эти cookie. В большинстве случаев лучше всего использовать » 0 «.

Если требуется функциональность автологина, реализовывайте его самостоятельно и никогда не используйте для этого долгоживущие сессии. Более подробно изложено выше в соответствующих разделах.

Несмотря на то, что HTTP-cookie имеют некоторые проблемы, всё же они наиболее предпочтительны для хранения идентификатора сессии. Когда это возможно, для управления идентификаторами сессий необходимо использовать «cookie». Большинство приложений должны использовать cookie для идентификатора сессии.

Если session.use_only_cookies =Off, модуль сессии будет использовать идентификатор, установленный через GET/POST/URL, если «cookie» не была выставлена заранее.

Это не позволит сессионному модулю использовать неинициализированные идентификаторы сессий. Другими словами, сессионный модуль будет принимать только корректные идентификаторы, сгенерированные им же и будет игнорировать идентификаторы созданные на стороне пользователя.

Из-за особенностей спецификации cookie, атакующий может сделать cookie с идентификатором сессии неудаляемой с помощью локальной базы cookie или JavaScript-инъекцией. session.use_strict_mode может не дать атакующему использовать этот идентификатор.

Атакующие могут инициализировать идентификатор сессии на своём устройстве и выставить его жертве. Они должны будут поддерживать сессию в активном состоянии для злоупотреблений. Атакующим понадобится совершить дополнительные действия для проведения атаки по этому сценарию. Поэтому session.use_strict_mode служит как предотвращение этому.

Запрещает доступ к сессионной cookie для JavaScript. Эта опция предотвращает кражу cookie с помощью JavaScript-инъекции.

Можно использовать сессионный ID как защитный ключ CSRF, но не рекомендуется. Например, HTML может быть сохранён и отправлен другому пользователю. Разработчик не должен записывать сессионный ID внутри страницы для повышения безопасности. Почти все приложения должны использовать атрибут httponly для сессионной cookie.

Защитный ключ CSRF должен периодически обновляться, как и идентификатор сессии.

Разрешает получать доступ к cookie идентификатора сессии только при использовании протокола HTTPS. Если ваш сайт использует только протокол HTTPS, вам необходимо включить эту опцию.

Для таких сайтов нужно также рассматривать использование HSTS.

Начиная с PHP 7.3, вы можете установить cookie-флаг «SameSite» для cookie идентификатора сессии. Этот флаг является способом смягчения атак CSRF (межсайтовая подделка запроса).

Разница между Lax и Strict заключается в доступности cookie в запросах, исходящих из другого регистрируемого домена с использованием HTTP-метода GET. Cookie, использующие Lax, будут доступны в GET-запросе, исходящем из другого регистрируемого домена, тогда как cookie, использующие Strict, не будут.

session.gc_maxlifetime=[выбрать наименьший из возможных]

session.gc_maxlifetime настройка для удаления устаревших идентификаторов сессий. Полагаться на эту опцию категорически не рекомендуется. Вы должны управлять жизненным циклом сессии самостоятельно.

По умолчанию GC работает на вероятностном принципе. Эта настройка не гарантирует удаление старых сессий. Разработчику не следует полагаться на эту настройку, но всё равно, рекомендуется выставить её минимально возможным значением. Настраивайте session.gc_probability и session.gc_divisor так, чтобы устаревшие сессии удалялись достаточно часто. Если требуется функциональность автологина, реализуйте его самостоятельно и никогда не используйте для этого долгоживущие сессии.

Читайте также:  Настройка ispy детектор движения

Некоторые обработчики сохранения сессий не используют механизм устаревания сессий на основе вероятностей. Например memcached, memcache. Читайте соответствующую документацию для более полной информации.

Использование прозрачного управления сессионным ID не рекомендуется. Вы можете использовать его, если необходимо. Однако, отключение прозрачного управления повышает безопасность сессий в целом, убирая возможность инъекции сессионного ID и его кражи.

Идентификатор сессии может утечь через закладку в браузере, URL посланный по почте, сохранённый исходник HTML.

(PHP 7.1.0 >=) Вы не должны перезаписывать ненужные HTML-теги. Значения по умолчанию должно быть достаточно для большинства случаев. Старые версии PHP для этого используют url_rewriter.tags.

Если session.use_trans_sid включён, то рекомендуется использовать эту опцию, если это возможно. Это уменьшает риск для инъекции сессионного ID. Если ваш сайт находится по адресу http://example.com/, то установите этой опции значение http://example.com/. Обратите внимание, что при использовании HTTPS, браузер не отправляет referrer заголовок. Таким образом, этот параметр не является достаточно надёжным показателем безопасности, но, всё же, рекомендуется его использовать.

Убедитесь, что содержимое HTTP не кешируется для аутентификационной сессии. Допускается кешировать только неконфиденциальный контент. Иначе содержимым могут воспользоваться. Можно использовать значение «private», если содержимое HTTP не содержит чувствительные к безопасности данные. Учтите, что «private» может оставлять конфиденциальные данные в общем кеше клиентов. Значение «public» можно использовать только, если HTTP-контент вообще не содержит никаких конфиденциальных данных.

(PHP 7.1.0 >=) Чем больше бит используется для символов идентификатора сессии, тем более надёжные идентификаторы будут созданы для той же длины идентификатора сессии.

(PHP 7.1.0 /tmp (по умолчанию), другие пользователи на сервере могут захватить сеансы, получив список файлов в этом каталоге.

Источник

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 и с функциями работы со строками. Для усвоения этого материала — отдельной статьи не нужно, хватит и мануала по приведенным ссылкам — никто за вас его читать не будет. Дерзайте!

P.S. Если узнали что-то новое из статьи — отблагодарите автора — зашарьте статью в социалках 😉
P.P.S. Да, это кросс-пост статьи с моего блога, но она актуальна и поныне 🙂

Серия статей «PHP для начинающих»:

Редакторский дайджест

Присылаем лучшие статьи раз в месяц

Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.

Похожие публикации

Несколько других советов для PHP-разработчиков

Ошибки начинающих PHP разработчиков

Как правильно объяснить начинающему php-программисту зачем, как и когда использовать ООП?

Курсы

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Минуточку внимания

Комментарии 41

Нет, он лишь внешне смотрится просто. Один только RFC 2616 занимает 176 страниц, а более новые RFC 7230-7235 — все 305 страниц в сумме

(если использовать метод GET, то строка запроса будет содержать логин и пароль, и может оказаться сохраненной на каких нибудь промежуточных прокси серверах, что очень плохо)

Прокси-серверы по определению видят ВЕСЬ запрос, в том числе тело и куки. Сохранить, соответственно, тоже могут что угодно куда угодно. Если же запрос зашифрованный (https, vpn и т.п.), то они не смогут увидеть ни тела, ни кук, ни строку запроса тоже. Если имеется в виду кеширование GET-запросов, то это отключается средствами HTTP, а POST-запрос нужен совсем не поэтому

Не такой уж и Secret, если флагов HttpOnly и Secure нет (впрочем, ниже по тексту HttpOnly упоминается)

Язык PHP создавался под стать протоколу HTTP — т.е. основная его задача — это дать ответ на HTTP запрос и «умереть» освободив память и ресурсы. Следовательно, и механизм сессий работает в PHP не в автоматическом режиме, а в ручном, и нужно знать что вызвать, да в каком порядке.

Из первого предложения никак не следует второе

расскажу о способах защиты [. ] будем запоминать User-Agent

Вообще не защита. User-Agent не является секретом и подбирается на ура, особенно для популярных браузеров

То есть после выхода новой версии браузера пользователь больше не сможет пользоваться сайтом?

То есть пользователи мобильных сетей больше не смогут пользоваться сайтом?

Этот заголовок вообще может установить пользователь как хочет, и опираться на него без предварительной настройки сервера нельзя

это уже более-менее будет походить на защиту от злоумышленников

Это будет походить на защиту от обычных пользователей, которые всего лишь обновили свой хром из гугл-плея и/или перебежали в другой макдональдс и потеряли доступ к сайту

эта настройка [HttpOnly] позволяет достаточно эффективно бороться с XSS атаками в практически всех браузерах

HttpOnly не имеет вообще никакого отношения к XSS. Если есть XSS, то ничто не мешает напакостить и, например, отправлять ajax-запросы без и чтения кук (куки к запросам на тот же origin автоматически добавит сам браузер)

«Для начинающих» не означает, что можно писать что-то не соответствующее действительности. Ну или в крайнем случае можно для упрощения объяснений, но с обязательной припиской о неточности и ссылкой для интересующихся, где почитать подробнее

я хотел донести главное, что её нужно внедрять

Судя по качеству продемонстрированноый защиты — на этой мысли и стоило остановиться, а сейчас реализация из статьи лишь несёт вред

Читайте также:  Настройка вайфая d link dir 300

Тем не менее, обычно в access-логах сохраняется именно url, а не содержимое тела запроса.

Передавать логин с паролем нужно через POST не для защиты от перехвата трафика, а для защиты от подобного сохранения в логах. Чтобы не получилось, что в БД все пароли хранятся строго в виде хешей и все как бы безопасно — а рядом лежит файлик с теми же самыми паролями в открытом виде.

Прокси-серверы по определению видят ВЕСЬ запрос, в том числе тело и куки. Сохранить, соответственно, тоже могут что угодно куда угодно

Вот именно про access.log и нужно было рассказать в статье, а прокси вообще не упоминать

Текущая формулировка лучше изначальной. Но access.log всё равно лучше упомянуть, потому что, в отличие от туманного какого-то там «логирования и кеширования», файлы access.log начинающий сможет найти без труда на почти любом хостинге

Ответ есть в официальном руководстве, но не в явном виде

Вы в этом точно уверены? Не хотите проверить?

Если ваше утверждение верно, то через 10 секунд сессия прервется. Я же утверждаю что она будет вполне себе живой до следующего прохода сборщика мусора.

Совсем не затронут вопрос создания «долгоиграющих» сессий. Т.е. таких, которые не прекращаются при закрытии браузера, а восстанавливаются даже через несколько дней.

Я, конечно, давно не делал ничего с сессиями на PHP (да и вообще на PHP), но меня терзает смутное сомнение, что при выполнении session_start() браузеру отправляется директива не приводящая к созданию файловой куки. Сессионный идентификатор хранится только в памяти браузера и уничтожается при закрытии браузера.

А чтобы создать файловую куку, нужно выполнить команду setcookie, причем с установленным достаточно большим временем ее жизни. И в эту куку уже записывать ID сессии или/и «билет» входа (сессионный пароль).

Хотя… извиняюсь, если что попутал.

Да… в последнее время у некоторых браузеров даже сессионные куки хранятся в БД. Но речь не столько о способе хранения, сколько о продолжительности. Раньше различие было четко — сессионные куки не хранились на диске в виде файлов или в БД, а информация длительного хранения записывалась в файловые куки. С тех пор многое изменилось. Но суть в том, что по session_start() в браузер передается директива Set-Cookie без указания срока хранения этой информации (с нулевым сроком), т.е. краткосрочная. А для создания куки длительного хранения используется setcookie с указанием срока годности этой информации.

Т.е. — это механизмы для создания сессий разного срока действия.

Но… действительно все зависит от браузера. Говорят, Хром не удаляет id сессий с нулевым сроком жизни при закрытии. И они могут быть использованы повторно.

При изучении сессий в свое время очень долго тупил по некоторым моментам (описание ситуация из 2004 года, а не сегодняшние):

1. Не работают сессии. О ней вы немного рассказали — нельзя выводить текст в браузер до старта сессии. Вообще никакой ни из какого файла — если старт сессии происходит в подключенном файле (include), то по пути до самой этой функции старта сессии ничего не должно выводиться в браузер. Я долго спотыкался о display_errors — когда о всех notice и warning инфа выдается в браузер (пример):

Пример больше надуманный, но сессия стартовать не будет, так как прилетит notice о том, что в массиве $_GET нет индекса logout — это неявная на первый взгляд ситуация. Но сам будучи новичком — нервов попила эта ситуация — я же нигде echo не вызываю!?

2. Я изначально думал, что сессии — это замена кукам, а потом сделал для себя «открытие», что для поднятие сессии можно идентификатор хранить в тех же куках, а не дергать его из параметров запроса в браузере на каждом файле. И что это дополняющие друг-друга функциональности.

3. Долго не мог понять, зачем вообще эти сессии помимо авторизации (разграничения доступа к определенному функционалу) — они ведь позволяют хранить вообще любые данные для конкретного пользователя на самом сервере, а не на клиенте. Но фишка как раз в том, что в сессии можно хранить данные, которые можно «передавать» между различными запросами, то есть что-то делал на одном шаге, сохранил состояние. Помню, что когда клепал каталог товаров с возможностью покупки, то хранил эти самые покупки в отдельном файлике — самописный функционал, файл назывался session_id.txt, то есть авторизацию проводил через сессию, а вот параметры хранил через свои костыли. До этого я просто не мог понять, читая статьи, что можно в сессиях хранить что-то больше, чем идентификатор. То есть для новичков пишут — хранить там можно все. А дальше нарисуй сову сам. А если бы объясняли на пальцах, что состояние корзины покупок мы можем хранить в массиве, который в свою очередь можем хранить в сессии и потом доставать из него штатными средствами php, чтобы решить задачу, а не изобретать костыли для ее решения.

4. Так же пояснять о том, что сессию «поднять» можно закрыв вкладку, но для этого нужно настроить куку, точнее ее время хранение и для какого домена (страниц) она должна отдаваться браузеру.

Я б не стал набирать комментарий, но вот кратко описал то, с чем столкнулся при изучении. Из статьи я тоже понял только то, что сессия позволяет распознавать пользователя на сайте. И все. Что там что-то можно хранить, но для чего это может понадобиться — не сказано. А если учитель привел бы конкретные примеры/ситуации или решение пусть того же to-do list через сессии — то есть завтра можно открыть вкладку и что-то дописать/отредактировать (потом как эту же задачу решить с помощью голого mysqli, затем как с помощью классов — PDO — тут же про иньекции и пр). Тут как раз можно было бы осветить большую часть возможностей, но уже вместе с практикой.

Нужно знать для чего инструмент (сессия) — для решения каких задач — корзина покупателя, авторизация, передача параметров между запросами в пять дней между самими запросами и т.д. — а не просто вот вам есть такой инструмент. Бывают конечно и исключения из правил — синяя изолента и молоток с ломом, но это уже другая история.

Какое-то большое имхо получилось…

Статья неплохая получилась, но хотелось бы чуточку «для чего это нужно», а не просто сухой текст.

Источник

Adblock
detector