Prowler behind Azure app gateway

[olsonnn]

Seems there was some good progress on running Prowler behind reverse proxy here
https://github.com/prowler-cloud/prowler/tree/master/contrib/reverse-proxy

And i'm trying to get it working in Azure App gateway.
https://mydomain.com/api/v1 is responding.
but when i login the UI is empty. no valid user/ user profile button. So i think connection to API is not ok internally?
not sure what i need to change in my .env. as well to get this working.

Edit:
when I try mydomain/profile it is loading...!!!

AUTH_URL=https://mydomain.com
API_BASE_URL=https://mydomain.com/api/v1
Django_allowed_hosts= ... mydomain.com

Logs in docker also not showing much as far as i can see...
Any help would be great!

[puchy22]

Hi @olsonnn 👋

Looking at your screenshot — the 404 body is <h1>Not Found</h1>, which is the Django default 404 response, meaning that request did reach the API container, but Django has no route at /api/v1/auth/session.

Here's the catch: /api/v1/auth/session isn't a path the UI code ever calls. The UI uses NextAuth, whose session endpoint is /api/auth/session (without /v1) and is served by the UI container, not the Django API. So the browser is requesting /api/auth/session, and something in your Azure App Gateway is rewriting the path to /api/v1/auth/session before forwarding it to the API backend. The most common cause is a backend HTTP setting on App Gateway with "Override backend path = /api/v1/", or a URL rewrite rule that prepends /api/v1/ to /api/* traffic.

That single misconfiguration explains everything you see:

• Login appears to succeed (it's handled by Next.js Server Actions inside the UI container, which talk to the API over the docker network — never through App Gateway).
• The browser then calls /api/auth/session to hydrate the session → App Gateway rewrites to /api/v1/auth/session → Django 404 → the UI has no user data → empty UI, no profile button.

Suggested fix: in App Gateway, the API path mapping needs to be exact-prefix /api/v1/* → API backend with no path override, and everything else (including /api/auth/* for NextAuth) → UI backend on port 3000. The bundled nginx reference at contrib/reverse-proxy/nginx.conf shows the routing/header shape that works.

To confirm before you touch the gateway config, could you share:

1. Your Prowler version (PROWLER_API_VERSION / PROWLER_UI_VERSION).
2. The App Gateway config: path-based routing rules, backend pools, and any backend HTTP setting that has a path override or rewrite rule.
3. From the browser DevTools Network tab right after login: the full list of failing requests, and for /api/v1/auth/session specifically, the Initiator column (it should point to NextAuth's client) — that confirms the browser was originally calling /api/auth/session and the rewrite happened at the edge.
4. Whether you're using the pre-built prowlercloud/prowler-ui:stable image or one you rebuilt — once the routing is fixed, you may also need to rebuild the UI with --build-arg NEXT_PUBLIC_API_BASE_URL=https://mydomain.com/api/v1 so the browser bundle calls your external host. Troubleshooting doc here.
5. The full set of environment variables resolved inside each container so we can rule out a config mismatch. You can grab them with:

   docker exec prowler-ui env | sort
   docker exec prowler-api env | sort

   Feel free to mask any secrets (AUTH_SECRET, DJANGO_SECRETS_ENCRYPTION_KEY, DJANGO_TOKEN_*, DB passwords, OAuth/SAML client secrets, etc.) — we mainly need the URL/host-related ones (AUTH_URL, API_BASE_URL, NEXT_PUBLIC_API_BASE_URL, DJANGO_ALLOWED_HOSTS, CORS_ALLOWED_ORIGINS if present, any SAML_* / SOCIAL_* callback URLs).

With those we should be able to confirm and unblock you. 🚀

[olsonnn]

Oh yes!!! /api/v1/* did the trick! instead of /api/*

Was scratching my head for hours ahha. Thank you so much!