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

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

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

• app.request.attributes.get ('_ route') пуст, когда я переопределяю страницу ошибок 404
• Переходы Laravel: класс «не найден»
• Скажите доктрине, что поле может быть нулевым
• Как использовать серверные переменные в тестах PHPUnit Test?
• Можно ли использовать установку Symfony2 (несколько сайтов на одном сервере)
• Symfony2 и Assetic - cssrewrite отлично работает для dev, а не для prod

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

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" } 

3. Использование прослушивателя
   Одним из самых популярных «решений» этой проблемы был этот из этого 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 и применить эти данные в новый пакет.

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

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

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

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

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

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

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

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

 $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; 

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