Infinite redirection loop when attempting to access a dockerized Airflow webserver using hostname

[Dev-iL]

Apache Airflow version

3.0.0

If "Other Airflow 2 version" selected, which one?

No response

What happened?

Spinoff from: #48825 (comment)

When accessing an instance of Airflow running via docker compose by accessing http://HOSTNAME:8080 (as opposed to http://localhost:8080), it results in a big "Unauthorized" message as well as an infinite redirection loop:

What you think should happen instead?

The UI should allow interaction.

How to reproduce

1. Include the following configurations in the default 3.0.0rc4 docker-compose.yaml file:

    # AIRFLOW__API__BASE_URL: UNSET!
    AIRFLOW__CORE__AUTH_MANAGER: airflow.api_fastapi.auth.managers.simple.simple_auth_manager.SimpleAuthManager
    AIRFLOW__WEBSERVER__BASE_URL: http://${VM_HOSTNAME}:8080

2. Set the environment variable VM_HOSTNAME to the hostname of the machine on which the container will be running.
3. Run the container and wait for the api server to boot.
4. Attempt to access the Airflow instance via http://${VM_HOSTNAME}:8080 - either from the machine on which the container is running, or from another one.

Operating System

Rocky Linux 9.3

Versions of Apache Airflow Providers

apache-airflow-providers-amazon           | 9.6.0
apache-airflow-providers-celery           | 3.10.6
apache-airflow-providers-cncf-kubernetes  | 10.4.2
apache-airflow-providers-common-compat    | 1.6.0
apache-airflow-providers-common-io        | 1.5.3
apache-airflow-providers-common-messaging | 1.0.0rc3
apache-airflow-providers-common-sql       | 1.25.0
apache-airflow-providers-docker           | 4.3.1
apache-airflow-providers-elasticsearch    | 6.2.1
apache-airflow-providers-fab              | 2.0.1rc0
apache-airflow-providers-ftp              | 3.12.3
apache-airflow-providers-git              | 0.0.2rc0
apache-airflow-providers-google           | 15.0.1
apache-airflow-providers-grpc             | 3.7.3
apache-airflow-providers-hashicorp        | 4.1.0
apache-airflow-providers-http             | 5.2.1
apache-airflow-providers-microsoft-azure  | 12.3.0
apache-airflow-providers-mysql            | 6.2.1
apache-airflow-providers-odbc             | 4.9.1
apache-airflow-providers-openlineage      | 2.2.0rc0
apache-airflow-providers-postgres         | 6.1.2
apache-airflow-providers-redis            | 4.0.2
apache-airflow-providers-sendgrid         | 4.0.1
apache-airflow-providers-sftp             | 5.2.0
apache-airflow-providers-slack            | 9.0.4
apache-airflow-providers-smtp             | 2.0.2
apache-airflow-providers-snowflake        | 6.2.1
apache-airflow-providers-ssh              | 4.0.1
apache-airflow-providers-standard         | 1.0.0rc0

Deployment

Docker-Compose

Deployment details

No response

Anything else?

CC: @ashb @pierrejeambrun @dheerajturaga

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[dheerajturaga]

@Dev-iL , I was locally able to work around the Unauthorized message. The default permissions for role User does not have access to view the items in the airflow3 home page.

I had to do the following: ( this maynot be the full set, but I hope you get the idea)
NOTE: This doesnt solve the infinite redirect.

airflow roles add-perms -v -r="User Stats Chart" -a=can_read User
airflow roles add-perms -v -r="User's Statistics" -a=menu_access User
airflow roles add-perms -v -r="View Menus" -a=can_read User

IMO, we need to add these permissions by default to role User. This needs to be added to the db migrate aswell so that folks transitioning to AF3 don't run into this

[Dev-iL]

@dheerajturaga In my comment on the previous post I also had the following, but since it didn't seem to affect the issue I omitted it from this ticket:

AIRFLOW__CORE__SIMPLE_AUTH_MANAGER_ALL_ADMINS: 'true'

Shouldn't that give the default user the necessary permissions?

[dheerajturaga]

Is your db clean? I would check the current permissions for the role "Admin"

I did notice even the role Admin was missing several permissions but the default ones were sufficient enough to load the page.

[Dev-iL]

Yeah, I tried it on a completely fresh DB/container. Regardless, I doubt it's related to permissions since everything works correctly when connecting to localhost:8080 instead of my.hostname:8080 (from the host itself). It would be a bit crazy if different permissions were assigned to the default user based on how the webserver was accessed (localhost vs. hostname).

[dheerajturaga]

Makes sense, I agree the Unauthorized maybe unrelated to perms.
I personally have a setup where a I use FabAuthManager for ldap based login and all new users get registered under role "User" and unfortunately the defaults for "User" doesn't include perms to access the home page

[ashb]

Strange, I'm not able to reproduce this

[Dev-iL]

Hmm... Is there any additional information I can provide to help with reproducing, or some change I can make to the airflow code or my configs to try and fix it?

Possibly related: fastapi/fastapi#7298

[Dev-iL]

Airflow log when connecting to the containerized webserver...

• ...using the hostname, from the hostname itself:

airflow-apiserver-1  | INFO:     172.30.116.82:56770 - "GET / HTTP/1.1" 200 OK
airflow-apiserver-1  | INFO:     172.30.116.82:56770 - "GET /ui/config HTTP/1.1" 401 Unauthorized
airflow-apiserver-1  | INFO:     172.30.116.82:56770 - "GET /api/v2/auth/login?next=http%3A%2F%2Fmy-hostname%3A8080%2F HTTP/1.1" 307 Temporary Redirect
airflow-apiserver-1  | INFO:     172.30.116.82:56770 - "GET /auth/token/login?next=http://my-hostname:8080/ HTTP/1.1" 307 Temporary Redirect
airflow-apiserver-1  | INFO:     172.30.116.82:56770 - "GET / HTTP/1.1" 200 OK
airflow-apiserver-1  | INFO:     172.30.116.82:56770 - "GET /ui/config HTTP/1.1" 401 Unauthorized
...

• ...using localhost, from the hostname itself:

airflow-apiserver-1  | INFO:     192.168.2.1:32896 - "GET / HTTP/1.1" 200 OK
airflow-apiserver-1  | INFO:     192.168.2.1:32896 - "GET /ui/config HTTP/1.1" 200 OK
airflow-apiserver-1  | INFO:     192.168.2.1:32896 - "GET /ui/auth/menus HTTP/1.1" 200 OK
airflow-apiserver-1  | INFO:     192.168.2.1:32896 - "GET /api/v2/plugins HTTP/1.1" 200 OK
airflow-apiserver-1  | INFO:     192.168.2.1:32896 - "GET /api/v2/version HTTP/1.1" 200 OK
airflow-apiserver-1  | INFO:     192.168.2.1:32930 - "GET /api/v2/importErrors HTTP/1.1" 200 OK
airflow-apiserver-1  | INFO:     192.168.2.1:32896 - "GET /ui/dashboard/historical_metrics_data?start_date=2025-04-21T09%3A24%3A16.320Z HTTP/1.1" 200 OK
airflow-apiserver-1  | INFO:     192.168.2.1:32912 - "GET /api/v2/monitor/health HTTP/1.1" 200 OK
airflow-apiserver-1  | INFO:     192.168.2.1:32924 - "GET /api/v2/assets/events?limit=6&order_by=-timestamp&timestamp_gte=2025-04-21T09%3A24%3A16.320Z&timestamp_lte=2025-04-22T09%3A24%3A16.320Z HTTP/1.1" 200 OK

• ...from a different machine, using the hostname [for completeness]:

airflow-apiserver-1  | INFO:     172.30.94.97:61067 - "GET / HTTP/1.1" 200 OK
airflow-apiserver-1  | INFO:     172.30.94.97:61067 - "GET /ui/config HTTP/1.1" 401 Unauthorized
airflow-apiserver-1  | INFO:     172.30.94.97:61067 - "GET /api/v2/auth/login?next=http%3A%2F%2Fmy-hostname%3A8080%2F HTTP/1.1" 307 Temporary Redirect
airflow-apiserver-1  | INFO:     172.30.94.97:61067 - "GET /auth/token/login?next=http://my-hostname:8080/ HTTP/1.1" 307 Temporary Redirect
airflow-apiserver-1  | INFO:     172.30.94.97:61067 - "GET / HTTP/1.1" 200 OK
...

The obvious difference is the network interface - 192.168.* seems fine, but 172.30.* seems to be unauthorized.