session_name

alpes

Весь мир на ладони
session_name

Блин, предыдущий топик закрыли, не успел запостить...

По поводу session_name.
поправте если я где-то мыслю по старинке, или мой учебник уже давно не актуален:

Ну что же начали мы работать из сессиями, но вскоре может возникнуть небольшая проблема. Дело в том что на одном и том же сайте может существовать сразу несколько сценариев, которые нуждаются в услугах поддержки сессий. Они "ничего не знают" друг о друге, поэтому временные хранилища для сессий должны выбираться не только на основе идентификатора, но и на основе того, какой сценарий запросил обслуживание сессии. Более подробно на примере:
Один разработчик "А" написал сценарий счетчика открытия страницы, используя в сессии переменную "count", и не имеет никаких проблем. До тех пор пока разработчик "В", ничего не знающий о сценарии "А", не создал систему статистики, которая тоже использует сессии. Самое ужасное, что он также решил для своих целей использует переменную "count", не зная о том что она уже занята. В результате, как всегда, страдает пользователь: запустив сценарий "В", а потом - "А", он видит что данные счетчика перемешались. Непорядок!
Собственно для предотвращения этого и дается разным группам сессий непересекающиеся имена, и сценарий знающий имя своей группы сессий, сможет получить к ней доступ. В примере скажем задав в коде "А" session_name("developer_A");, а в коде "В" session_name("developer_В"); можно избавить себя от неприятностей.
 

RomikChef

Guest
все не относящиеся к этой теме сообщения удалены.
 

alpes

Весь мир на ладони
All, так что с session_name, не помешает, или всеже не нужна?
 

RomikChef

Guest
очень хорошо, что ты не успел написать в ту тему.
потому, что разные вопросы разных людей должны обсуждаться в разных темах.

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

Отдельно замечу, что рецепты для такого бездумного сайта не надо выдавать ночичкам, изучающим основы сессий.

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

ForJest

- свежая кровь
Если это все работает в пределах одного проекта то что тебе мешает выделить для каждой из частей проекта свой массив в сессии?
$_SESSION["developer_A"] = array();
$_SESSION["developer_B"] = array();

И сообщить об этом девелоперам. Таким образом в пределах сайта у тебя будет единое хранилище - с одиним именем, но каждый девелопер будет пользовать свое пространство имен.
 

alpes

Весь мир на ладони
Да, можно и так. Вроде все просто, но тогда накой понадобилось создавать функцию session_name() ?!
Я вижу смысл токо в том случае когда отсутствует планирование (каждый ваяет мелкие части по принцыпу "что ему взбредет") или же на одном сайте размещается, например, два различных проекта.
 

ForJest

- свежая кровь
А ты предлагаешь убрать эту функцию?
Чтобы у всех был PHPSESSID и без никаких?
Я например в каждом проекте ставлю свое имя сессии - нравится мне так.
 

alpes

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

RomikChef

Guest
из-за таких, "не вредных" функций и получаются программы, в которых сам черт ногу сломит.

Работает? Ничего не трогай.
Все прекрасно работает и с дефолтными настройками.

Если уж вы пишете программы по желанию левой пятки, то не надо на форуме передавать от нее советы не в тему. Договорились?
 

alpes

Весь мир на ладони
Если я правильно понял, ты советуешь для чистоты программирования эту функцию не юзать?
 

RomikChef

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

В результате из программы в две строчки получится 200.
потом в ней кто-то будет разбираться и гадать - а зачем здесь ЭТО? А можно ли убрать без потери функциональности? Агде, среди десятка строк НЕОБЯЗАТЕЛЬНОГО кода лежит одна-единственная, которая что-то делает РЕАЛЬНОЕ, которая и нужна при поиске ошибки.
 

ForJest

- свежая кровь
Нет ну с чисто эстетической точки зрения меня уже воротит от PHPSESSID. Поэтому session_name - это супер необходимая функция для моего душевного комфорта :).
 

alpes

Весь мир на ладони
Ромик, хорошо, когда тогда необходимо юзать session_name ?
 

RomikChef

Guest
Я не знаю таких случаев.
может быть, более опытные товарищи подскажут.

Но если учесть, что она дублирует директиву PHP.INI, то можно с уверенностью сказать, что без нее всегда можно обойтись.
 

WiZARD

Guest
не всегда, в некоторых случаях когда ваяеться навороченый скрипт в бальшой конторе например я в свое время под интранет шо-то подобное ваял,
И под каждое отделение фирмы была выделена session_name так как параметры одинаковые и скрипты тоже, контора большая и в каждом регионе по серваку, это кстати очень удобно.....
 

alpes

Весь мир на ладони
На счет PHP.INI, хочу заметить, при использовании у хостера правка php.ini отобразится на все хосты.

На счет "неообходимо" - все же считаю всегда, почему:
Во-первых, как было замечено чисто из эстетических соображений.
Во-вторых, это хороший тон давать каждому проекту свое имя. Я тут случайно вспомнил где я работал с сессиями и обнаружил что для одного и того же сайта писал большой проект в котором устанавливал session_name("имя компании"). В этом проекте пользователь авторизуется через сессии. И тут же для этого же сайта написал модуль "File Manager" (удаления, редактирования, аплоада и т.п. рабочих скриптов, етно все на SSL) также содержащий авторизацию через сессии. И машинально дал имя сессиям этого модуля "FaileManager". В этом случае, во-первых, избежал путаницы когда управляющий персонал сначала авторизуется как пользователь сайта а затем, зайдет в FileManager, во-вторых модуль "File Manager" можно без проблем использовать на любом другом сайте, который тоже использует авторизацию, при этом не боясь за пересечение использования одних и тех же имен переменных.

Может, кто-то дополнит, или прокритикует, буду только признателен.
 
Сверху