OAuth Redirect URI for general OAuth wrong

[TheSander562]

Dear,

It seems in the latest version (DockFlare 3.0.5), the redirect URI is not totally correct.
When setting up my OAuth Providers with Authelia it all works, but only when i set in Authelia my redirect URI to HTTP like:

• http://cf.domain.nl/auth/samarium/callback

When using HTTPS this doesnt work and i get an Authelia issue that the redirect URI doesnt match.
So is it possible it is automatically set to HTTPS or make it an option (if not already)

The URL it gives to go to Authelia:
https://auth.domain.nl/api/oidc/authorization?response_type=code&client_id=dockflare&redirect_uri=http%3A%2F%2Fcf.domain.nl%2Fauth%2Fsamarium%2Fcallback&scope=openid+email+profile&state=sSkKFLMt-ArRVQ3SCUronZPb5NINxnYeUuf-OjFwX9c&nonce=gjZSdj1Vn2AgI0ZWsf41

[ChrispyBacon-dev]

I can look into this again however I did some tests when I was implementing this and I'm certain I used https. Possible to share the docker labels (anonymize domain.tld)?

Thanks

[TheSander562]

This is for logging into DockFlare itself so not sure what you want to see with my compose:
And in my oauth provider i have set this issuer URL: https://auth.domain.nl

Let me know if something else is needed.

services:
 dockflare-docker-proxy:
   image: tecnativa/docker-socket-proxy:latest
   container_name: dockflare-docker-proxy
   environment:
     PUID: 1031
     PGID: 100
     TZ: Europe/Amsterdam
     DOCKER_HOST: unix:///var/run/docker.sock
     CONTAINERS: 1
     EVENTS: 1
     NETWORKS: 1
     IMAGES: 1
     POST: 1
     PING: 1
     INFO: 1
     EXEC: 1
   volumes:
     - /var/run/docker.sock:/var/run/docker.sock:ro
   networks:
     - dockflare-intern
   restart: unless-stopped

 dockflare:
   image: alplat/dockflare:stable
   container_name: dockflare
   depends_on:
     dockflare-docker-proxy:
       condition: service_started
     dockflare-redis:
       condition:  service_healthy
   environment:
     TZ: Europe/Amsterdam
     STATE_FILE_PATH: /app/data/state.json
     LABEL_PREFIX: cloudflare.tunnel
     SCAN_ALL_NETWORKS: false
     CLOUDFLARED_NETWORK_NAME: apps_network
     MAX_CONCURRENT_DNS_OPS: 3
     DOCKER_HOST: tcp://dockflare-docker-proxy:2375
     REDIS_URL: redis://dockflare-redis:6379/0
   volumes:
     - /mnt/data/container_data/dockflare/data:/app/data
   networks:
     - default
     - dockflare-intern
   labels:
     caddy: cf.domain.nl
     caddy.import: authentication
     caddy.reverse_proxy: "{{upstreams 5000}}"
     caddy.reverse_proxy.header_up: Cookie "samarium_sessie=[^;]+" "samarium_sessie=_"
   restart: unless-stopped

 dockflare-redis:
   image: redis:latest
   container_name: dockflare-redis
   volumes:
     - /mnt/data/container_data/dockflare/redis:/data
   networks:
     - dockflare-intern
   healthcheck:
     test: redis-cli ping || exit 1
   restart: always

networks:
 dockflare-intern:
 default:
   name: apps_network
   external: true

[TheSander562]

And for going to Authelia through the Cloudflare tunnel it is using these labels on the authelia container:

    labels:
      caddy_0: auth.domain.nl
      caddy_0.reverse_proxy: "{{upstreams 9091}}"
      caddy_1: (authentication)
      caddy_1.forward_auth: authelia:9091
      caddy_1.forward_auth.uri: /api/verify?rd=https://auth.domain.nl
      caddy_1.forward_auth.copy_headers: Remote-User Remote-Groups Remote-Name Remote-Email
      dockflare.enable: true
      dockflare.hostname: auth.domain.nl
      dockflare.service: http://authelia:9091

[ChrispyBacon-dev]

sorry I don't understand you use caddy ? I understood that you want to use oAuth for authentication on DockFlare correct? So why use Caddy in between instead of an CF tunnel endpoint?

general oAuth means for me authentication via oAuth provider for DockFlare control plane. correct?

see -> https://dockflare.app/docs/oauth-provider-setup

for oAuth IdP in CF see -> https://dockflare.app/docs/identity-providers

PS: Authelia is fully tested and supported.

[TheSander562]

Well you said to share my labels 😅.
But yes I want to protect the DockFlare login with authelia and indeed it is working but I need to set my redirect URI in authelia config to use HTTP instead of HTTPS
That is my issue, so it’s creating the redirect URI as HTTP and not HTTPS in DockFlare when setup the OAuth provider

That’s why I have the URL in the issue :
The URL it gives to go to Authelia:
https://auth.domain.nl/api/oidc/authorization?response_type=code&client_id=dockflare&redirect_uri=http%3A%2F%2Fcf.domain.nl%2Fauth%2Fsamarium%2Fcallback&scope=openid+email+profile&state=sSkKFLMt-ArRVQ3SCUronZPb5NINxnYeUuf-OjFwX9c&nonce=gjZSdj1Vn2AgI0ZWsf41

[moofur]

Adding a second report here to help clarify the root cause, as I hit exactly the same issue with Authentik.

Root cause: Flask is not trusting the X-Forwarded-Proto header from the reverse proxy

When DockFlare runs behind a reverse proxy (nginx, Caddy, Traefik, etc.) that terminates TLS, the proxy connects to DockFlare internally over plain HTTP on port 5000. From Flask's perspective, every incoming request arrives over HTTP — it never sees the original HTTPS connection the user made.

When Flask generates the OAuth callback URL using url_for(..., _external=True), it infers the scheme from the request it sees, which is http. The result is a callback URL like:

http://dockflare.yourdomain.com/auth/<provider-id>/callback

...even though the user is browsing over HTTPS. This causes the redirect URI mismatch error in any OIDC provider that has https://... registered.

The proxy is sending an X-Forwarded-Proto: https header — Flask just isn't trusting it, because by default Flask ignores forwarded headers as a security measure (to prevent header spoofing).

The fix: apply Werkzeug's ProxyFix middleware

This is the standard solution for Flask apps behind reverse proxies. In the application factory (wherever the Flask app object is created), add:

from werkzeug.middleware.proxy_fix import ProxyFix
app.wsgi_app = ProxyFix(app.wsgi_app, x_proto=1, x_host=1)

The x_proto=1 tells Flask to trust one level of X-Forwarded-Proto, which causes url_for(..., _external=True) to generate https:// URLs correctly. The x_host=1 similarly trusts X-Forwarded-Host for hostname construction.

ProxyFix ships with Werkzeug, which Flask already depends on — no new packages required.

Suggested enhancement: make it opt-in via an environment variable

Unconditionally trusting forwarded headers is technically incorrect for users running DockFlare without a reverse proxy (direct port exposure), where a malicious client could spoof these headers. A safer approach would be to gate the middleware on an env var:

if os.environ.get("TRUST_PROXY_HEADERS", "false").lower() == "true":
    app.wsgi_app = ProxyFix(app.wsgi_app, x_proto=1, x_host=1)

Users behind a reverse proxy would then add TRUST_PROXY_HEADERS=true to their compose environment, and it could be documented alongside the OAuth setup guide. Given that DockFlare is almost always deployed behind a reverse proxy in practice, applying it unconditionally would also be a reasonable default — but the env var approach is the cleaner solution.

Secondary issue: session cookie lost on the HTTP redirect

Even if you work around the mismatch by registering the http:// callback URI in your OIDC provider, the auth flow will fail at the final step. After the provider redirects back to the http:// callback URL, the browser briefly touches HTTP before nginx upgrades it to HTTPS. If DockFlare's session cookie has the Secure flag set (as it should), the browser will not send the cookie on that HTTP request, causing the session to be lost and the user to be dumped back to the login screen. This is the second failure mode people are seeing.

Both issues are resolved by the ProxyFix fix above, which makes Flask generate correct https:// callback URLs from the start.

Confirmed affected setup: nginx reverse proxy → DockFlare on port 5000, Authentik as OIDC provider.

[moofur]

Update: Working fix found

After digging into the source, here's what's actually happening and what fixes it.

Root cause

login_provider in routes.py has a branch that constructs the callback URL correctly using a hardcoded https:// scheme — but only if app.config['DOCKFLARE_PUBLIC_HOSTNAME'] is populated. If it isn't, it falls back to url_for(..., _external=True), which generates an http:// URL because Flask isn't aware it's sitting behind a TLS-terminating reverse proxy.

The critical detail is how DOCKFLARE_PUBLIC_HOSTNAME gets populated. Looking at main.py, it is only set from the dockflare.hostname Docker label on the DockFlare container itself. It is not read from any environment variable. So setting DOCKFLARE_PUBLIC_HOSTNAME as an env var in your compose file does nothing.

The fix

Add the dockflare.hostname label to the dockflare container in your compose file:

services:
  dockflare:
    image: alplat/dockflare:stable
    labels:
      - "dockflare.hostname=dockflare.yourdomain.com"

Note: dockflare.enable=true is not needed and should not be added — without it, DockFlare will not attempt to manage itself as a tunnel-connected service. The dockflare.hostname label alone is sufficient to populate DOCKFLARE_PUBLIC_HOSTNAME and trigger the correct https:// callback URL path in login_provider.

Things that do NOT fix this (so others don't go down the same path)

• Setting PREFERRED_URL_SCHEME=https as an env var — not a recognised variable at the url_for level
• Adding Werkzeug ProxyFix middleware — fixes url_for scheme inference, but login_provider doesn't use url_for for the callback URL when DOCKFLARE_PUBLIC_HOSTNAME is set, so ProxyFix alone doesn't help
• Setting DOCKFLARE_PUBLIC_HOSTNAME as an environment variable — never read from env, only from the Docker label

Suggested improvements for the developer

1. The documentation for OAuth setup should mention the dockflare.hostname label as a required step for users behind a reverse proxy.
2. DOCKFLARE_PUBLIC_HOSTNAME (or the existing DOCKFLARE_PUBLIC_URL setting, which IS configurable via env/UI) should be usable as a fallback in login_provider so users have an alternative to the Docker label approach. The DOCKFLARE_PUBLIC_URL field already exists in the settings page and is loaded correctly — login_provider just doesn't check it.

Confirmed working setup: nginx reverse proxy → DockFlare on port 5000, Authentik as OIDC provider.

[ChrispyBacon-dev]

Hi Moofur,

Thank you for the investigation. I believe this is an edge case because the usual or standard deployment directly uses a CF tunnel. Out of curiosity, why do you use nginx reverse proxy instead of Cloudflare Tunnel?

For your input, I suggest adding this to the known problems in the documentation and describing it as an edge case. The main recommendation is to fully utilize Cloudflare Tunnel with a zero-trust access policy. You are more than welcome to raise an PR for documentation into the unstable branch and I will provide language translations.

[moofur]

Thanks for the response! To answer your question: I deliberately keep DockFlare off the tunnel because it only needs to be accessible inside my local network. A Zero Trust policy would work, but it's unnecessary overhead for something that never needs to leave my LAN.

I take the point about it being an edge case in terms of deployment topology, and I'm happy to contribute documentation. That said, I'd push back a little on framing the underlying issue as purely an edge case concern.

The dockflare.hostname label is a tunnel management directive. Its side effect of populating DOCKFLARE_PUBLIC_HOSTNAME — which is what actually makes the OAuth callback URL build correctly — is nowhere documented, and is genuinely surprising behavior. A user setting up OAuth who isn't attaching DockFlare to a tunnel has no reason to know that label is relevant to them, let alone required.

The existing DOCKFLARE_PUBLIC_URL field in Settings already exists for exactly this kind of configuration — it's just not wired into the callback URL construction in login_provider. That feels like the more natural fix regardless of deployment topology: OAuth callback URL generation probably shouldn't depend on a Docker label at all.

Happy to raise a PR for the docs in the meantime. Would you also be open to a small code PR wiring DOCKFLARE_PUBLIC_URL into login_provider as a fallback?

[ChrispyBacon-dev]

Hmm, yes, I want to spend more time on this, but I’m currently deep in the development of CloudFlare Email Routing support. I’ve linked the discussion below. In three days (16th April), CloudFlare will have the Email send functionality with workers in public beta. You can check out my announcement online here:
#340