Назад | Перейти на главную страницу

Использование `#` в регулярном выражении местоположения nginx?

В моей конфигурации nginx для Kibana есть два следующих блока. Моя цель - предоставить два уровня доступа: один для доступа к панели инструментов, визуализации и страниц поиска Kibana (для разработчиков), а второй - для доступа к инструментам управления и разработки (для администраторов Elasticsearch).

server {
    listen 80;

    server_name elk.ops.example.com;

    location ~* "(app\/.*\#\/management.*|app\/timelion.*|app\/.*\#\/dev_tools.*)" 
        auth_basic "Restricted Access";
        auth_basic_user_file /etc/nginx/htpasswd.admin;
        proxy_pass http://localhost:5601;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }


    location / {
        auth_basic "Restricted Access";
        auth_basic_user_file /etc/nginx/htpasswd.users;
        proxy_pass http://localhost:5601;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

Когда я работаю с этой конфигурацией, http://elk.ops.example.com/app/timelion правильно приводит к 403 Запрещено при доступе неавторизованных пользователей, однако оба http://elk.ops.example.com/app/kibana#/management?_g=() и http://elk.ops.example.com/app/kibana#/dev_tools/console?_g=() оставаться доступным.

Я пробовал все способы фильтра регулярных выражений в первом блоке местоположения, чтобы безуспешно ограничивать эти два пути. Мне стало ясно, что проблема связана с # в URL-адресе, есть ли что-то особенное в # с nginx, которое вызывает проблемы?

Причина, по которой это не работает, заключается в том, что # персонаж никогда не отправляется на сервер. К сожалению, с помощью nginx этого не избежать.