Настройка выглядит следующим образом:
Веб-сайт A → собственный .env (website-a.env) с БД site_a.
Веб-сайт B → собственный .env (website-b.env) с DB site_b.
API A → собственный .env (api-a.env), с БД api_a.
API B → собственный .env (api-b.env), с DB api_b.
Веб-сайты выполняют API-вызовы к API.
Ожидаемое поведение:
Веб-сайт A должен использовать свой собственный .env (website-a.env) только для своей собственной логики (например, его БД, пользователи, переводы).
Когда веб-сайт A отправляет запрос к API A, запрос должен быть получен API A, а API A должен использовать собственный .env (api-a.env) для подключения к собственной базе данных (api_a).
То же самое относится и к веб-сайту B → если веб-сайт B вызывает API A, API A все равно должен загружать api-a.env, а не веб-сайт-b.env. (та же концепция для API B)
Другими словами: каждый проект должен использовать только свой собственный .env и никогда не наследовать настройки .env от вызывающего объекта.
Проблема:
Когда веб-сайт A делает запрос к API A, запрос обрабатывается с использованием .env с веб-сайта A вместо API A.
Это означает, что API A пытается запросить базу данных site_a с помощью databaste.table в формате веб-сайта_a.api_keys, хотя его собственный .env явно указывает на api_a.
Если веб-сайт Б вызывает API A, то вместо него применяется .env с веб-сайта Б.
Таким образом, API не изолирован — похоже, он «наследует» среду вызывающего объекта.
Пример ошибки:
Код: Выделить всё
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'website_a.api_keys' doesn't existЭто не работает, только когда его вызывает другой проект Laravel.
Что я пробовал:
Очистил все кеши с помощью php artisan оптимизировать:clear в каждом проекте.
Проверено с помощью маршрутов отладки, что правильный .env загружается при прямом доступе.
Добавлен .user.ini с opcache.cache_id для разделения OPcache для каждого проекта, но Laragon/Apache, похоже, не учитывает его.
(phpinfo() показывает, что opcache.cache_id => не имеет значения.)
Когда я вручную запускаю каждый проект с помощью php artisan serve --port=xxxx на разных портах, проблема исчезает. Каждое приложение Laravel использует правильный .env и базу данных.
Проблема возникает только тогда, когда я позволяю Laragon/Apache обрабатывать все сайты (с HTTPS и виртуальными хостами). В этом случае API-интерфейсы, кажется, «выкачивают» конфигурацию среды с веб-сайта вызывающего абонента.
Вопрос:
Как я могу убедиться, что каждый API Laravel в настройке Laragon всегда использует только свой собственный .env и соединение с базой данных, а не наследует среду вызывающего абонента?
Это известная проблема OPcache/mod_php с Laragon (общий процесс PHP).
Или есть какой-то шаг настройки, который я использую? не хватает правильной изоляции сред между несколькими проектами Laravel?
Подробнее здесь: https://stackoverflow.com/questions/797 ... ple-projec
