NGINX Reverse Proxy - Not Proxy Auth

I am trying to setup ROR Enterprise behind an NGINX reverse proxy for load blancing across multiple backend/upstream servers but am stuck with the same/similiar issues described in Using nginx reverse proxy for readonlyrest pro
Tho unlike it I am not trying to replace the ROR authentication with NGINX.

Using the nginx config

    location /kibana {
        proxy_pass https://kibana;
        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;
    }

results in a 404 with a url of https://proxyserveraddress/login?next=/kibana/. Navigating to https://realdeviceaddress/kibana presents the same url response, though without the 404 error. This make sense since its not going through the proxy, though the added ?next=/kibana is confusing me.

Setting the server.basePath property in the kibana.yml file to "/kibana" should resolve the issue however in by doing so ROR enters an infinite loop.

I’m not sure what I am missing or misunderstanding for this to function. Most of the result in the forums in regards to proxy use only refer to use proxy-auth. If there are any examples or explanations on how to operate this correctly it would be appreciated.

Hi Matthew, can you check what infinite loop? I.e. from chrome dev tools. What URLs are you being bounced back and forth from/to.

login?next=/kibana/kibana/login

(NGINX)

(DIRECT)

So i was messing around and i think i figured out what’s going on. On NGINX I altered the location statement to:

    location /kibana/ {
        proxy_pass https://kibana/;
        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;
    }

This meant that the location /kibana set via nginx no longer gets forwarded to the proxy destination server and in theory it should return a 404 Not Found error since the server.basePath was changed … however it presented a rendered ROR login page. This means that ROR is responding on https://realdeviceaddress:5601/login and not on what I assumed would be https://realdeviceaddress:5601/kibana/login. Sure enough navigating directly to https://realdeviceaddress:5601/login revealed the ROR login page … though not entirely rendered.

Logging into https://proxyserveraddress/kibana/login works perfectly because Kibana is responding with the prefix /kibana on its redirects and NGINX is no longer enforcing it on the login call.


Using https://realdeviceaddress:5601/login to login successfully results in the same redirect loop as if you were attempt to access https://realdeviceaddress:5601/kibana/login. This is because the response from the server is appending /kibana to the redirects. So while going to https://realdeviceaddress:5601/login presents the a login page, logging in still has redirects affected by the server.basePath and alters the calls to https://realdeviceaddress:5601/kibana/login … which does not exist.


Given that I am not aware of the inner workings of the ROR plugin or which calls are made, how, or when my assumption is that the user is not actually authenticated or given the appropriate tokens needed to be considered logged in. Since navigating to the root of kibana, in the case the altered server.basePath, https://realdeviceaddress:5601/kibana the user is redirected to https://realdeviceaddress:5601/kibana/login. Thus the redirect loop occurs.


Looking back at the non-rendered logo image we can see that the attempted url to retrieve the image was https://realdeviceaddress:5601/kibana/plugins/readonlyrest_kbn/img/readonlyrest-logo-white.png. If altreted to https://realdeviceaddress:5601/plugins/readonlyrest_kbn/img/readonlyrest-logo-white.png the images loads. This suggests that this is not solely related to /login.


Is this the expected behaviour or is ROR not appropriately accounting for server.basePath?