Lockdown or disable reaching /API/ subdirectory

1. Describe your incident:
I am assuming this is by design but I can not for the life of me figure out how to lock down access to the /API/ subdirectory . The API portal has it’s own authentication fields like how I expect. All other subdirectory redirect you to the main login page as it should. Only the /API/ subdirectory does not. Yes, TLS is being forced.

2. Describe your environment:

  • OS Information:
    Docker running on Ubuntu 22.04 LTS

  • Package Version:
    Official graylog-open docker compose

  • Service logs, configurations, and environment variables:
    Docker is currently behind Nginx Proxy Manager by Jc21, HTTPS TLS is forced
    link URI is
    public URI is pointing to Nginx.
    Single node setup
    Firewall rules only allow specific devices on a VPN subnet range to connect as well as entries for specific servers for log transmission
    All configurations work fine and Graylog is perfectly reachable from devices that need to reach the server

~Nginx Adv Config~
add_header X-Xss-Protection “1; mode=block” always;
add_header X-Content-Type-Options “nosniff” always;
add_header X-Frame-Options “SAMEORIGIN” always;
proxy_hide_header X-Powered-By;
add_header ‘Referrer-Policy’ ‘no-referrer’;
add_header Permissions-Policy “accelerometer=();ambient-light-sensor=(); autoplay=();camera=();encrypted-media=();focus-without-user-activation=(); geolocation=();gyroscope=();magnetometer=();microphone=();midi=();payment=();picture-in-picture=(); speaker=();sync-xhr=();usb=();vr=()”;
add_header Content-Security-Policy upgrade-insecure-requests;
add_header Strict-Transport-Security “max-age=31536000; includeSubDomains”;
~Nginx Adv Config End~

3. What steps have you already taken to try and solve the problem?
Reddit, official Graylog forum, general Google searches, speaking with those I know who run the same setup, looking through documentation, looking through server.conf.

4. How can the community help?
Locking down of the /API/ subdirectory to force you back to login page if you are not logged in to the Graylog client. I am assuming this isn’t something due to Nginx as every other subdirectory requires authentication as expected.

I do know this is doable somehow as doing a Google search for the API results in finding an internet exposed global API portal found here. However if you go to the /API/ subdirectory it properly redirects back to the main login page.

I appreciate any help on this, thanks.

Hi @spardok

We are in direct acces to a rpm based environment.

If we go to the <ip/dns>:9000/API/ directory we are redirected to the logon screen.

Could it be due to be bind to what means any interface/ip is listening
to incoming requests? We have set this to the host ip addres or dns name.

kind greetings, Arie

1 Like

Hi Arie,

Thanks for the reply. I’ve tried configuring the bind in the past and I have not gotten the docker image to boot up without it being set to

I’ve tried the hosts hostname, FQDN, IP, Nginx hostname, IP, and FQDN. I have also tried the docker image address as well. All configuration settings result in the same network error while trying to boot the docker image.

The OS firewall is off.

Hi @Spardock

I am not completely familiar with docker in this, in docker one configures
an inside port and an outside port eg 9000:9000

Maybe it is something there al-tho it is strange that in a docker image
the /api/ directory is unsafe.

Kind greetings,


I don’t believe this is a docker problem. Exposing the port basically just tells docker to expose that port to the host system, and then you just go from there like any normal port listening in.

The only other thing I can think of, because it’s on an internal network and I am using Nginx. I am using it as a reverse proxy, so HTTP from Graylog to Nginx which translates it to HTTPS. Maybe something within Graylog when you tell Graylog itself to use TLS will automatically cause /API/ to redirect to login, whereas if you use HTTP → HTTPS to a reverse proxy Graylog doesn’t.

We have Graylog running internally on http, and on http there is a redirect to the login page. So something with user authentication could go wrong in your setup somehow i think in relation to user sessions.

Could be worth an issue on Githup.

Even on HTTP? that’s interesting. I’m going to try maybe taking it off pointing to Nginx and see what happens if i just use straight HTTP then. I have someone I know also doing the same set up I am and his as well does not point back to login when he goes to the /api/ subdirectory.

If it redirects on my HTTP test I’ll go ahead and put an issue in.

I am indeed seeing the same issue with HTTP not running through the Nginx server. My guess is it’s either the Bind URI, which I can’t seem to change without it breaking. Or perhaps it’s a Docker issue?