I have figured out it using proxy on Django side https://pypi.org/project/django-revproxy/. So Flower is hidden behind Django auth which is more flexible than basic auth. And you don’t need rewrite rule in NGINX.

Flower 0.9.5 and higher

URL prefix must be moved into proxy path: https://github.com/mher/flower/pull/766

urls.py

urlpatterns = [
    FlowerProxyView.as_url(),
    ...
]

views.py

class FlowerProxyView(UserPassesTestMixin, ProxyView):
    # `flower` is Docker container, you can use `localhost` instead
    upstream = 'http://{}:{}'.format('flower', 5555)
    url_prefix = 'flower'
    rewrite = (
        (r'^/{}$'.format(url_prefix), r'/{}/'.format(url_prefix)),
     )

    def test_func(self):
        return self.request.user.is_superuser

    @classmethod
    def as_url(cls):
        return re_path(r'^(?P<path>{}.*)$'.format(cls.url_prefix), cls.as_view())

Flower 0.9.4 and lower

urls.py

urlpatterns = [
    re_path(r'^flower/?(?P<path>.*)$', FlowerProxyView.as_view()),
    ...
]

views.py

from django.contrib.auth.mixins import UserPassesTestMixin
from revproxy.views import ProxyView


class FlowerProxyView(UserPassesTestMixin, ProxyView):
    # `flower` is Docker container, you can use `localhost` instead
    upstream = 'http://flower:5555'

    def test_func(self):
        return self.request.user.is_superuser

I wanted flower on a subdirectory of my webserver, so my nginx reverse proxy configuration looked like this:

location /flower/ {
    proxy_pass http://localhost:5555/;
    proxy_redirect off;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Protocol $scheme;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_http_version 1.1;

    auth_basic  "Restricted";
    auth_basic_user_file  /etc/nginx/.htpasswd;
}

Now I can get to flower (password-protected) via www.example.com/flower

Most of this is derived from the Flower documentation page about configuring an nginx reverse proxy:

http://flower.readthedocs.org/en/latest/reverse-proxy.html

I followed @petr-přikryl’s approach using a proxy view. However I couldn’t get it to verify authentication (I don’t think test_func is ever called). Instead I chose to embed this in the Django Admin views and use AdminSite.admin_view() (as described here) to wrap the view with Django Admin authentication.

Specifically, I made the following changes:

# Pipfile
[packages]
...
django-revproxy="*"

# admin.py
class MyAdminSite(admin.AdminSite):
    # ...
    def get_urls(self):
        from django.urls import re_path

        # Because this is hosted in the root `urls.py` under `/admin` this 
        # makes the total prefix /admin/flower
        urls = super().get_urls()
        urls += [
            re_path(
                r"^(?P<path>flower.*)$",
                self.admin_view(FlowerProxyView.as_view()),
            )
        ]
        return urls

# views.py
from __future__ import annotations

from django.urls import re_path

from revproxy.views import ProxyView


class FlowerProxyView(ProxyView):
    # Need `/admin/` here because the embedded view in the admin app drops the
    # `/admin` prefix before sending the URL to the ProxyView
    upstream = "http://{}:{}/admin/".format("localhost", 5555)

Lastly, we need to make sure that --url_prefix is set when running flower, so I set it to run like this in our production and dev environments:

celery flower --app=my_app.celery:app --url_prefix=admin/flower

This is a reply to Petr Přikryl’s post. django-revproxy fails to work on my Django 4.1.x project. I am encountering error AttributeError: 'HttpResponse' object has no attribute '_headers'. Many others are facing the same issue. brianmay in the issue thread claims, "I think this project is basically dead, sorry."

I went with a different library to serve as a workaround.

Install django-proxy

This is what my code looks like.

# urls.py

from django.urls import re_path
from myapp.views import flower


urlpatterns = [
    re_path("flower/(?P<path>.*)", flower),
]

# views.py

from django.views.decorators.csrf import csrf_exempt
from proxy.views import proxy_view

@csrf_exempt
def flower(request, path):
    extra_requests_args = {}
    remoteurl = f"http://localhost:5555/flower/" + path
    return proxy_view(request, remoteurl, extra_requests_args)

Then run celery with

$ celery --app myproject flower --loglevel INFO --url_prefix=flower

You can then view it in your browser, served through Django, at http://localhost:8000/flower/.

Additional notes:

–url_prefix= is important because this will allow the proxy to serve the static files that flower requests.

If you are using docker compose, then you will likely need to change the hostname in the remoteurl string in the flower function to reflect the same of the service. For example, my service is appropriately called flower in my docker-compose.yaml file. Therefore, I would change the string from f"http://localhost:5555/flower/" to f"http://flower:5555/flower/"

To offload the django app, I suggest you use the X-Accel-Redirect header in order to use nginx to proxy the Flower server. It goes as follow:

1. the user requests the flower path (e.g. /task)
2. nginx proxy_pass the request to your app, as usual
3. your django app chooses to accept or reject the request (e.g. based on authentification)
4. if your app accepts the request, it returns a response with X-Accel-Redirect HTTP-header together with a string of an internal location, i.e. a path that cannot be accessed directly by the user
5. nginx intercepts the response instead of forwarding it to the user and uses it as a new path with the possibility this time to access internal locations, in our case the Flower server

If the request is rejected, simply do not use X-Accel-Redirect and handle the case as any other rejected request you’d implement.

nginx.conf:

upstream celery_server {
    server /var/run/celery/flower.sock;
}

upstream app_server {
    server /var/run/gunicorn/asgi.sock;
}

server {
    listen 80;

    location /protected/task {
        internal;  # returns 404 if accessed directly
        proxy_http_version 1.1;
        proxy_redirect off;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header Upgrade $http_upgrade;

        proxy_pass http://celery_server/task;
    }

    location / {
        proxy_http_version 1.1;
        proxy_redirect off;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $server_name;

        proxy_pass http://app_server;
    }
}

views.py:

from django.contrib.admin.views.decorators import staff_member_required
from django.views.decorators.csrf import csrf_exempt
from django.http import HttpResponse


class XAccelRedirectResponse(HttpResponse):
    def __init__(self, path, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self['X-Accel-Redirect'] = '/protected' + path
        del self['Content-Type']  # necessary


# I chose to only allow staff members, i.e. whose who can access the admin panel
@staff_member_required
@csrf_exempt
def task_app(request, path):
    query_str = request.META['QUERY_STRING']  # you must keep the query string
    return XAccelRedirectResponse(f'/task/{path}?{query_str}')

urls.py:

from django.urls import re_path
from app import views


urlpatterns = [
    re_path('task/(?P<path>.*)', views.task_app, name='task'),
]

Flower

It is important to change the url-prefix of Flower:

celery flower --unix-socket="/var/run/celery/flower.sock" --url-prefix="task"

Yep there’s not auth on flower, since it’s just talking to the broker, but if you run it over SSL then basic auth should be good enough.

How would HTTP and HTTPS affect Celery security? What user logins are you referring to?

Flower monitors to a Celery queue by attaching to the workers. When setting up Flower you need to provide connection string [broker]://[user_name]:[password]@[database_address]:[port]/[instance]. User name and password are the credential to log into the database of your choice.

If you’re referring to this login, wouldn’t simply disable/remove their logins be suffice?