Проблемы с устаревшим Symfony, медленно переносящий массивный проект

Итак, у нас есть этот проект MASSIVE bare metal php, который мы хотим медленно преобразовать в Symfony3

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

Поэтому решение, которое мы решили попробовать, было следующим:

  1. Вставьте все приложение в / web
  2. Храните сценарий аутентификации в устаревшем приложении (он слишком сложный, чтобы переносить на новый, а затем обновлять старый, чтобы использовать новую систему сеансов), поскольку все, что он делает, это установить пару ключей $ _SESSION
  3. Нигде в приложении не устанавливаются какие-либо переменные сеанса, просто аутентификатор.

Проблема в том, что страдания, связанные с конфигурацией Legacy Bridge , и несколько вариантов переполнения стека вариантов ответов, которые нигде не получили.

  1. Использование моста
    Конфигурирование с помощью моста, как говорит этот документ , не повлияло ни на что, кроме того, что сеанс, который он читал, ничего не добавил в $_SESSION['_sf2_attributes'] или где-то еще.

  2. Использование компонента Bridge
    В соответствии с этим документом, который описывает использование компонента PhpBridgeSessionStorage , когда он сконфигурирован, будет выводиться по строкам:

ContextErrorException в строке class.php 83: Warning: ini_set (): активен сеанс. Вы не можете изменить настройки ini-модуля сеанса в это время

Когда я совмещаю его с первым методом, он становится в точности первым методом. Он работает, НО я вижу абсолютно NONE данных сеанса, установленных в устаревшем приложении, в моем контроллере symfony

 DefaultController.php on line 16: array:3 [▼ "_sf2_attributes" => & [] "_sf2_flashes" => & [] "_sf2_meta" => & array:3 [▼ "u" => 1469839893 "c" => 1469836213 "l" => "0" ] ] DefaultController.php on line 17: Session {#2519 ▼ #storage: PhpBridgeSessionStorage {#2520 ▼ #bags: array:2 [▼ "attributes" => AttributeBag {#2218 ▼ -name: "attributes" -storageKey: "_sf2_attributes" #attributes: & [] } "flashes" => FlashBag {#2219 ▼ -name: "flashes" -flashes: & [] -storageKey: "_sf2_flashes" } ] #started: true #closed: false #saveHandler: SessionHandlerProxy {#2522 ▼ #handler: SessionHandler {#2217} #wrapper: true #saveHandlerName: "files" } #metadataBag: MetadataBag {#2521 ▼ -name: "__metadata" -storageKey: "_sf2_meta" #meta: & array:3 [▼ "u" => 1469839893 "c" => 1469836213 "l" => "0" ] -lastUsed: 1469839892 -updateThreshold: "0" } } -flashName: "flashes" -attributeName: "attributes" } 
  1. Использование прослушивателя
    Одним из самых популярных «решений» этой проблемы был этот из этого SO-ответа

Но при настройке и настройке с помощью прослушивателя в app/config/services.yml вот так: services: session.legacy: class: AppBundle\Session\LegacySessionHandler tags: - { name: kernel.event_listener, event: kernel.request, method: onKernelRequest }

мы получаем ошибку:

LogicException в строке NativeSessionStorage.php 240: невозможно зарегистрировать сумку, когда сеанс уже запущен.

Я понимаю, что это решение пытается сделать, но это накладывает две проблемы с моей стороны:

Я чувствую, что к моменту kernel.request и метода моих классов событие должно по-прежнему видеть фактический реальный набор данных за пределами контекста symfony, хранящегося в супер-глобальном $_SESSION . Как предполагается, чтобы любопытный цикл через $ _SESSION и применить эти данные в новый пакет.

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

Вторая проблема заключается в том, что по какой-то причине я заблокирован от регистрации нового пакета …

  1. Подход «F-it»

Поскольку я мог бы _sf2_attributes такие ключи, как _sf2_attributes в устаревшем приложении, когда я var_dump супер-глобальный $_SESSION , я решил, почему бы не просто заставить аутентификатор сбросить свои ключи в ключ _sf2_attributes а не из корня!

Это тоже не сработало. Вроде, вообще. Ничего из этого не появляется в моем контроллере symfony.


Я здесь близок к концу. Это ошибка, это по дизайну?

Solutions Collecting From Web of "Проблемы с устаревшим Symfony, медленно переносящий массивный проект"

У меня была эта же проблема и она была решена, добавив это в config.yml:

 session: storage_id: session.storage.native handler_id: session.handler.native_file save_path: ~ 

Для отладки я использовал следующий PHP-код в двух местах: 1) в устаревшем скрипте. 2) в контроллере Symfony.

 $sessPath = ini_get('session.save_path'); $sessCookie = ini_get('session.cookie_path'); $sessName = ini_get('session.name'); echo '<br>sessPath: ' . $sessPath; echo '<br>sessCookie: ' . $sessCookie; echo '<br>sessName: ' . $sessName; 

Моя проблема заключалась в том, что session.save_path был другим для symfony и устаревшим приложением. Поэтому код symfony не смог получить доступ к моим старым переменным $ _SESSION.

Добавив следующую строку, config.yml исправил проблему:

save_path: ~

После того, как я исправил это, код контроллера symfony может видеть все переменные $ _SESSION напрямую:

 echo "<pre>"; print_r($_SESSION); echo "</pre>"; 

Нет необходимости в «классе LegacySessionHandler реализует решение EventSubscriberInterface», упомянутом в другом вопросе stackoverflow. (часть 3 этого вопроса)