Будет ли PHP-код приложения всегда иметь доступ для чтения / удаления к файлам сеанса на одном и том же сервере?

Question

Будет ли PHP-код приложения всегда иметь доступ для чтения / удаления к файлам сеанса на одном и том же сервере?

Для моей Joomla! Расширение 3.8+ Мне нужно иметь возможность находить и удалять (отменять связь) файлы сессий PHP (с именем ‘sess_’ + идентификатор сессии), которые будут храниться в session_save_path, например, / TMP. Я понимаю, что это PHP хранит файлы сессий, то есть не Joomla! (Обработчик сессии Joomla! Установлен на «PHP»)
Мой вопрос: будет ли файл сессии PHP, созданный с помощью Joomla! сайт ВСЕГДА будет доступен для чтения / записи с помощью PHP-кода моего расширения, который является частью того же Joomla! установить?

Дополнение: позже я понял, что я опустил слово «всегда» в своем вопросе, который я сейчас добавил.

Дополнение: Более подробное объяснение того, чего я пытаюсь достичь.
Как я уже сказал, у меня есть Joomla! сайт, на котором пользователи могут войти.
Вопрос касается ТОЛЬКО когда Joomla! настроен с обработчиком сеанса, установленным на «PHP» (вместо «база данных»). Когда Session Handler — это «база данных», проблем нет.

В общих чертах, я хочу добиться следующего (с обработчиком сессии Joomla!, Установленным в ‘PHP’):

1> Пользователь открывает браузер A и входит в веб-сайт и Joomla!
записывает связанный идентификатор сеанса плюс идентификатор пользователя в базе данных.

2> Один и тот же пользователь открывает другой браузер B (возможно, с другим IP)
и хочет войти на тот же сайт.

3> Поскольку пользователь уже зашел на сайт через браузер A,
он / она не имеет права войти в систему снова и будет представлен
кликабельная ссылка, которая уничтожит все остальные его сеансы, включая
один с браузером A (мы записали идентификаторы сеанса всех остальных
сеансы).

Простая session_destroy () на шаге 3 только частично делает свое дело, потому что разрушенные детали сессии вновь появляются через некоторое время в Joomla! бэкэнд, а также в Joomla! сессионный стол. Хотя это не мешает Joomla! передний конец, это не чисто, и я хочу избежать этого, чтобы сделать его дураком.
Безусловно, лучшим решением было бы, если бы я мог удалить файл сеанса PHP (например, в dir / tmp и с именем ‘sess _….’). Я проверил это, и он работал нормально. Однако … он полагается на то, что у вас всегда есть доступ для удаления к файлу сеанса PHP (с использованием session_save_path () и unlink ($ session_file_path)), и это основа вопроса, который я написал.
Я обнаружил, что удаление файла сеанса PHP не всегда возможно; это зависит от конфигурации PHP провидора. Поскольку я разрабатываю это коммерческое приложение, процесс должен работать со всеми конфигами, в том числе с теми, которые не позволяют удалить доступ к файлу сеанса.

Я продолжу поиск решения и опубликую его здесь, когда найду.

2

destroy php read-write session

Решение

Другие решения

Это зависит от настроек сервера.

Найти пользователя, который использует PHP: Как проверить, какой пользователь php работает?
Проверьте разрешения этого пользователя в папке, где хранятся сессии: Unix: Как проверить разрешения для определенного каталога?
Измените разрешения при необходимости: https://serverfault.com/questions/105535/how-can-i-set-full-premissions-to-a-user-in-a-specified-dir

0

Спасибо @Nigel и @AgeDeO

Методом проб и ошибок я обнаружил, что ответ НЕТ, не всегда.
Выполнив код с несколькими коммерческими провайдерами, я столкнулся с одним провайдером, который не позволил мне удалить файл сеанса PHP, пока он находился в месте по умолчанию. Расположение было / var / lib / php5.

0

Источник

Accepted Answer

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

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

Лучшим решением было бы иметь вторичную таблицу недействительные идентификаторы сессий.

Затем вы пишете пользовательский плагин, подключающий onUserAuthorization а также onUserLogout События. Тебе понадобится onAfterInitialise тоже.

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

При выходе пользователя идентификатор текущего сеанса удаляется из таблицы, а сеанс уничтожается.

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

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

1