Совместная работа с другими ресурсами на домене

[TM123]

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

Использую 2.0.31 или 32, так же используется Yii 1.1.? с помощью шаманства была сделана проброска авторизации туда и обратно, так что пользователи работают с функционалом сделанным на разных фреймворках прозрачно. В марте поставили PHP 7.3, отгребли некоторое количество проблем, все позатыкали, но появилась плавающая проблема с отказом в авторизации, сначала это все выглядело так, что авторизация перестала пробрасываться из 1 в 2, т.е. пользователь авторизовывался в 1, а при попытке зайтие в 2, все уходило в бесконечный цикл открытия формы авторизации на 2. Проблема проявлялась в контексте одного браузера, т.е. если в браузере возникла, то ..., при этом при открытии тут же в другом браузере все нормально работало какое-то время. Проблема плавала и не повторялась, в какой-то момент стало ясно что какие-то проблемы в cookie, все выглядело как в 2 авторизация проходит нормально, дальше cookie устанавливаются нормально, а потом после выполнения redirect на ранее запомненный URL, cookie просто не оказывалось и предлагается авторизоваться заново. Поставили принудительную очистку cookie в браузере, проблема на время ушла, но через некоторое время стали появляться пользователи, у которых вообще переставало работать и они не в 1, ни в 2 не могли попасть даже после очистки cookie, отключили авторизацию через 1, оставили только в 2, опять большинство проблем ушло, но через некоторое время стало появляться все больше пользователей, у которых и в этом случае ничего не работало, просто бесконечное предложение залогиниться.

На прошлой неделе ситуацию удалось устойчево повторить, начал отлаживаться и обнаружил следующее.
Проект на Yii работает допустим на yii.domain.ru - живет на nginx, есть корпоративный сайт на битриксе на www.domain.ru - живет на apach. В результате, если пользователь сначала зашел на WWW, то он больше не сможет зайти на Yii, если очистить cookie, зайти на Yii, а потом на WWW, то все будут жить весело и счастливо. Стал копать дальше, обнаружил, что битрикс устанавливает cookie для ".domain.ru", а далее от браузера прилетают сразу cookie и от .domain.ru и от yii.domain.ru, порядок прилета определяется куда пользователь сначала зашел, на www или yii, в результате получается что если пользователь был сначала на www, то yii получает сначала PHPSESSIONID от apach Битрикс, т.е. не свой, а потом через пару cookie прилетает и родной PHPSESSIONID, но Yii берет первый попавшийся PHPSESSIONID и дальше, пока недокопался, но судя по всему отказывается его признавать или сам PHP отказывается признавать и в результате не смотря на наличие корректной авторизации и установленных корректных cookie требует авторизации.

Есть другие ресурсы работающие на php на других доменах 3-его уровня, проверяли, на них это дело не влияет, они без проблем различают cookie от своего домена и от www и нормально работают, хотя возможно у них другой способ подтверждения подлинности и у них нет этой проблемы.

После повторения проблемы стало понятно, почему прекращало работать вообще, если у пользователя была открыта вкладка с www, то она обращалась к www при старте браузера и устанавливала cookie, а yii выдавал форму логина и не устанавливал cookie, поэтому в этом случае всегда оказывался вторым.

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

[TM123]

В общем ковыряние в cookie браузере и анализ cookie от других сайтов на домене навели на мысли. В php.ini поменял значение параметра session.name = YIIPHPSESSID и проблема решилась.

Тем не менее глубинные вопросы остались и ощущение того что это было какое-то временное и неправильное решение, тем более что на одном сервере и домене 2-го уровня живут 3 Yii проекта каждый на своём домене 3-его уровня, а php.ini у них один. Бегло посмотрел класс Session и не нашел там параметра с именем параметра в котором хранится идентификатор сессии. Подскажите как правильно разрулить средствами Yii эту ситуацию, если конечно ее можно легко разрулить.

[skynin]

если конечно ее можно легко разрулить.

У нас - несколько независимых сайтов, бек один, функционал для сайтов отличается не сильно, бек слегка меняет поведение, по источнику запроса
Авторизации как через три главных соц сети, так возможна и регистрация на любом из сайтов

Тоже столкнулись с проблемами. И решили влоб - перешли на yii\web\DbSession
То есть отказались от борьбы с штатной авторизацией, а перешли на управляемую нами.
DbSession не лучший выбор если большая нагрузка, но нам с головой хватает.

см https://www.yiiframework.com/doc/guide/ ... ns-cookies
Пользовательское хранилище для сессии

-- так же используется Yii 1.1
могут быть проблемы, возможно придется портировать от Yii2

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

[TM123]

По поводу пользовательского хранилища сессий - это интересно, посмотрю. По настоящему у нас помимо проброса авторизации между 1 и 2 есть еще проблема, которая мне давно не нравится - это то что для проброса авторизации между серверами, они по сети смотрят в одну директорию главного сервера, где он хранит свои сессии, а остальные пользуются этой папкой. Такой подход создает потенциальные проблемы для работы всех серверов в этой схеме из-за сетевых блокировок файлов, что замедляет работу + есть ощущение того, что могут быть проблемы и с транзакционным доступом к файлу сессии, которая без проблем обеспечивается транзакционной файловой системой в рамках одного сервера, но как она работает и работает ли вообще при сетевом доступе к файлу. Проблем пока не было, но подсознательно есть ощущение тревоги относительно такого решения.

[skynin]

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

Совершенно верно.

И от файлового хранения все равно придется уходить.

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

А так - значит должно быть централизованное хранение сессий, и точно не файловое, а сервис на одном из серверов.

Если большая нагрузка - берите реализации для Redis. Понятно что его нужно будет где-то поднять.
Если попробовать, или нагрузка типичная, то DbSession и его таблички можно прямо с основными держать. Все равно ж сервер БД уже поднят

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