0

I have the following two blocks in my nginx config for Kibana. My goal is to provide two levels of access, one to access the dashboard, visualization, and discover pages of Kibana (for developers) and a second level that can access the management and dev tools (for Elasticsearch admins).

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

When I run with this configuration, http://elk.ops.example.com/app/timelion correctly results in 403 Forbidden when accessed by unauthorized users, however both http://elk.ops.example.com/app/kibana#/management?_g=() and http://elk.ops.example.com/app/kibana#/dev_tools/console?_g=() remain accessible.

I've tried all manners of regex filter on the first location block to restrict those two paths without any luck. It's become clear to me that the problem is with the # in the URL, is there something special about # with nginx that is causing problems?

LegendaryDude
  • 204
  • 4
  • 10
  • I found the answer after some more digging over on stackoverflow. Is it acceptable to answer here with the same basic information, or should this be migrated to SO and closed as a duplicate? It probably makes sense to answer here so that future users can more easily find the answer they're looking for? – LegendaryDude Dec 13 '16 at 21:35
  • Since this is off topic at [so], you should probably answer it here. – Michael Hampton Dec 13 '16 at 22:27
  • There is some special with # in browsers, they do not send hash part to server – Alexey Ten Dec 14 '16 at 06:02

1 Answers1

0

The reason this doesn't work is that the # character is never sent to the server. Unfortunately, there is no way around this using nginx.

LegendaryDude
  • 204
  • 4
  • 10