New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow URI for X-Graylog-Server-URL to be relative. #2156

Merged
merged 1 commit into from May 4, 2016

Conversation

Projects
None yet
2 participants
@dennisoelkers
Member

dennisoelkers commented Apr 28, 2016

This helps us to not rely on having a properly configured, publicly
visible, consistent absolute URL for the Graylog server. This makes
configuration a lot simpler for example for setups where both the web and
the REST port are exposed on a single port with a URL prefix for the
latter ("/api" for example), because in this case we can set
X-Graylog-Server-URL to a relative URI, regardless of the hostname.

Allow URI for X-Graylog-Server-URL to be relative.
This helps us to not rely on having a properly configured, publicly
visible, consistent absolute URL for the Graylog server. This makes
configuration a lot simple for example for setups where both the web and
the REST port are exposed on a single port with a URL prefix for the
latter ("/api" for example), because in this case we can set
X-Graylog-Server-URL to a relative URI, regardless of the hostname.

@dennisoelkers dennisoelkers added the web label Apr 28, 2016

@dennisoelkers dennisoelkers added this to the 2.0.1 milestone Apr 28, 2016

dennisoelkers added a commit that referenced this pull request Apr 28, 2016

Returning an explicit session validation response instead of http status
This helps us to prevent basic auth popups showing up for the request,
because of browsers intercepting 401s for non-CORS requests. Helps a lot
when the web interface is served over a single port using a relative
server URL like proposed and enabled in #2156.

joschi added a commit that referenced this pull request May 2, 2016

Return explicit session validation response instead of HTTP status (#…
…2157)

This helps us to prevent basic auth popups showing up for the request,
because of browsers intercepting 401s for non-CORS requests. Helps a lot
when the web interface is served over a single port using a relative
server URL like proposed and enabled in #2156.

joschi added a commit that referenced this pull request May 3, 2016

Return explicit session validation response instead of HTTP status (#…
…2157)

This helps us to prevent basic auth popups showing up for the request,
because of browsers intercepting 401s for non-CORS requests. Helps a lot
when the web interface is served over a single port using a relative
server URL like proposed and enabled in #2156.
(cherry picked from commit 5eb97e8)

@kroepke kroepke self-assigned this May 4, 2016

@kroepke

This comment has been minimized.

Member

kroepke commented May 4, 2016

@dennisoelkers I either struggle to configure this correctly, or there's a missing piece in the setup:

I have configured nginx like:

  server
    {
      listen      6001;
      server_name 172.16.0.17;

      location /
      {
          proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header    Host $http_host;
          proxy_set_header    X-Graylog-Server-URL /api;
          proxy_pass          http://127.0.0.1:8080;
      }

      location /api/
      {
          proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header    Host $http_host;
          proxy_pass          http://127.0.0.1:12900/;
      }
    }

Using that configuration and visiting http://172.16.0.17:6001/ works as expected, but the internal metrics calls fail with:

2016-05-04 14:45:41,409 WARN : org.graylog2.shared.rest.resources.ProxiedResource - Unable to call http://172.16.0.17:6001/system/metrics/multiple on node <3040048c-8935-4c24-8307-0218fa6fbeeb>, result: Not Found

It appears the resource doesn't take the correct url into account. This might be unrelated.

Relevant server config:

rest_listen_uri = http://127.0.0.1:12900/
rest_transport_uri = http://172.16.0.17:6001/api/
web_endpoint_uri = http://172.16.0.17:6001/

This is running the webpack dev server, but that should not make a difference.

@kroepke

This comment has been minimized.

Member

kroepke commented May 4, 2016

In this case the metrics cannot be loaded, of course.

@dennisoelkers

This comment has been minimized.

Member

dennisoelkers commented May 4, 2016

For this scenario, you neither need to set rest_transport_uri nor web_endpoint_uri. The Graylog server shouldn't use the proxy for calling itself (or other nodes), so it should use rest_listen_uri. This is actually the good thing about the X-Graylog-Server-URL-header, because it allow per-proxy configuration and does not require special server configuration.

@kroepke

This comment has been minimized.

Member

kroepke commented May 4, 2016

After correcting my server config, by leaving out rest_transport_uri, this works as intended.

@kroepke kroepke merged commit bf68ae7 into 2.0 May 4, 2016

4 checks passed

ci-server-integration Jenkins build graylog2-server-integration-pr 872 has succeeded
Details
ci-web-linter Jenkins build graylog-pr-linter-check 360 has succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@kroepke kroepke deleted the relax-format-for-server-url-header branch May 4, 2016

joschi added a commit that referenced this pull request May 10, 2016

Allow URI for X-Graylog-Server-URL to be relative. (#2156)
This helps us to not rely on having a properly configured, publicly
visible, consistent absolute URL for the Graylog server. This makes
configuration a lot simple for example for setups where both the web and
the REST port are exposed on a single port with a URL prefix for the
latter ("/api" for example), because in this case we can set
X-Graylog-Server-URL to a relative URI, regardless of the hostname.
(cherry picked from commit bf68ae7)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment