Здравствуйте

имеется балансировщик с 6 бэкендами php-fpm  7.0
есть nginx c ip_hash

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

ради эксперимента скопировал со всех бэкендов каталоги сессий и обнаружил
около 200 совпадений на ~ 50 000 сессий

для исправления ситуации были применены следующие настройки:

session.hash_bits_per_character = 6
session.hash_function = sha512

коллизий стало меньше, но в целом ситуация не решилась

кто как решает подобные задачи?

ps:  php 7.0  и обновление до 7.1 в дистрибутиве из официальных источников не предусмотрено :(

• коллизия сессий PHP,PavelR, 13:56 , 21-Ноя-16
  • коллизия сессий PHP,tester0, 14:53 , 21-Ноя-16
  • коллизия сессий PHP,Admin00ad, 17:54 , 23-Ноя-16
    • коллизия сессий PHP,tester0, 17:59 , 23-Ноя-16
      • коллизия сессий PHP,PavelR, 06:56 , 24-Ноя-16
• коллизия сессий PHP,Sw00p_aka_Jerom, 02:14 , 24-Ноя-16

> ps:  php 7.0  и обновление до 7.1 в дистрибутиве из
> официальных источников не предусмотрено :(

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

1) А что, в php-7.1 это как-то решено?
2) Если там это решено, то обычный путь - это собирать свои пакеты, пусть и на базе дистрибутивных правил сборки.
3) вы поддержали nginx inc финансово? Тогда там есть https://www.nginx.com/products/session-persistence/
4) Еще есть какие-то открытые подобные модули, как описано в https://habrahabr.ru/post/231523/

> 1) А что, в php-7.1 это как-то решено?

да, там появились

https://secure.php.net/manual/ru/session.configuration.php#i...
https://secure.php.net/manual/ru/session.configuration.php#i...

А точно генерится та длинна хэша сессии чтов настройках ? В 5 версии пхп модули сессий и хэша приходилось компилить жестко в бинарник пхп, модулем не работало.

> А точно генерится та длинна хэша сессии чтов настройках ? В 5
> версии пхп модули сессий и хэша приходилось компилить жестко в бинарник
> пхп, модулем не работало.

да, хэши стали длиннее

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

попробовали в memcache,  работает -но будет ли гарантироваться там уникальность ключей...

>> А точно генерится та длинна хэша сессии чтов настройках ? В 5
>> версии пхп модули сессий и хэша приходилось компилить жестко в бинарник
>> пхп, модулем не работало.
> да, хэши стали длиннее
> может кто подскажет как по правильному общее хранилище сессий организовать?
> попробовали в memcache,  работает -но будет ли гарантироваться там уникальность ключей...

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

Гарантировать _уникальность_ задачей _хранилища_ не является.

Два бэкенда всё так же могут сгенерировать два одинаковых ключа (второй перезапишет первый).

>около 200 совпадений на ~ 50 000 сессий

200 совпадений чего ? имен сессионных файлов ? это у вас клиенты некоторые у которых менялись айпишки передавали уже назначенный PHPSESSIONID и прыгали по бекандам, у sha512 коллизий на 50к итераций (если взять в качестве ключа микросекунды запроса) количество коллизий практически равны нулю.

пс:

http://www.acros.si/papers/session_fixation.pdf
session.use_strict_mode=On

можно ещё юзать централизованное хранилище вроде мемкешеда, либо базы.