Шаблон vhost Nginx regex закінчується як ім'я сервера PHP


12

У мене є визначення сервера nginx із збігом регулярних виразів, як це:

server_name ~^(?<vhost>[a-z0-9-]+)\.example\.com$;
root /var/www/example/$vhost;
access_log /var/log/nginx/$vhost.example-access.log;

Все добре працює, однак у цьому домені розміщуються різні проекти PHP, використовуючи fastcgi та PHP-FPM, які отримують такі значення у $_SERVER:

SERVER_NAME => "~^(?<vhost>[a-z0-9-]+)\.example\.com$"
HTTP_HOST   => "myhost.example.com"

Як бачимо, шаблон регулярного вираження вводиться, SERVER_NAMEа не рядок, з яким він збігався. Це здається мені трохи невдалим, а також представляє ризик для безпеки, оскільки він виявляє непотрібні деталі (в інших конфігураціях я збігаю специфічний набір імен, а не макіяж).

Ви можете сказати "використовувати HTTP_HOST замість SERVER_NAME" - якщо тільки це було так просто - є бібліотеки, які очікують, що SERVER_NAME (не дивно) містить ім'я сервера. Я не можу реально сприймати корисний приклад для такої поведінки.

Відповіді:


14

Завдяки ефекту гуми-качки, коли я написав це питання, я знайшов рішення.

Фондовий fastcgi_paramsфайл Nginx містить рядок:

fastcgi_param  SERVER_NAME        $server_name;

що є причиною появи цього значення $_SERVER['SERVER_NAME']в середовищі PHP.

Я змінив це для використання змінної $ host :

fastcgi_param  SERVER_NAME        $host;

і моя проблема пішла. Мені буде цікаво знати, чи є якісь недоліки у цього підходу.


Єдиним недоліком у цьому підході є те, що він покладається на змінну $ host, що означає, що він може бути перезаписаний користувачем, якщо він надсилає заголовок HTTP_HOST. Ви можете перевірити це за допомогою curl: curl --header "HOST: google.com" http://yourdomain/yourpage.phpта у yourpage.php put: <?php echo $_SERVER['SERVER_NAME']; ?>Ви побачите google.com
Ghulam Ali

2
server_name  ~^(?<subdomain>.+)\.example\.com$;
set $server_name_full $subdomain.example.com;


location ~ \.php$ {
    ...
    include fastcgi_params;
    fastcgi_param SERVER_NAME $server_name_full;
    ...
}

3
Хоча код цінується, він завжди повинен мати супровідне пояснення. Це не повинно бути довгим, але очікується.
peterh
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.