[Feature Request] Support for custom/configurable HTTP headers to eliminate reverse proxy auth bypass rules

[PottiMc]

Problem

When running Dawarich behind an authenticating reverse proxy like [Pangolin](https://github.com/fosrl/pangolin), API endpoints (/api/v1/overland/batches, /api/v1/owntracks/points, etc.) are blocked by the proxy's authentication wall. Tracking apps (Overland, OwnTracks, Dawarich iOS/Android app, GPSLogger, Home Assistant) cannot complete browser-based SSO, so these requests get rejected.

The common workaround is adding a path-based bypass rule (/api/* → Bypass Auth) on the reverse proxy. This works, but it completely disables the proxy's authentication layer for the entire API surface, which undermines the layered security model.

Pangolin already supports Access Token authentication via HTTP headers:

P-Access-Token-Id: <token-id>
P-Access-Token: <token-value>

When these headers are present on a request, Pangolin authenticates the request without requiring browser-based SSO — no bypass rule needed.

The problem is that Dawarich currently has no way to instruct tracking apps to include these headers, nor does it pass them through in any configurable way.

Proposed Solution

Add a configuration option in Dawarich (via settings UI and/or environment variables) to define custom HTTP headers that should be included in API documentation and/or required on incoming API requests.

Option A: Document custom headers for tracking apps (minimal change)

Provide a settings field where users can define custom headers (key-value pairs). These headers would then be displayed in the account settings / API configuration section alongside the existing API key, so users can configure their tracking apps accordingly.

Most tracking apps already support custom headers:

• Overland: Supports custom HTTP headers in settings
• OwnTracks: Supports custom HTTP headers
• Dawarich iOS/Android app: Could include a custom headers field in settings
• Home Assistant REST command: Supports arbitrary headers via headers: config

This way, the user would:

1. Create a Pangolin Access Token (shareable link) for the Dawarich resource
2. Enter the P-Access-Token-Id and P-Access-Token values as custom headers in their tracking app
3. Remove the /api/* bypass rule from Pangolin

Option B: Server-side custom header validation (additional security layer)

In addition to Option A, Dawarich could optionally validate a custom header on incoming API requests as an extra authentication factor:

environment:
  - CUSTOM_API_HEADER_NAME=X-Dawarich-Secret
  - CUSTOM_API_HEADER_VALUE=my-shared-secret

This would add defense-in-depth: Pangolin validates the access token, and Dawarich validates an additional shared secret.

Example flow (with Option A)

Tracking App (e.g. Overland)
    │
    │  POST /api/v1/overland/batches?api_key=xxx
    │  P-Access-Token-Id: e4ghmv2r
    │  P-Access-Token: zidg2yfrm5q8942792237opaxa
    │
    ▼
Pangolin (Reverse Proxy)
    │  → Validates Access Token headers → Request authenticated
    │  → No bypass rule needed for /api/*
    ▼
Dawarich
    │  → Validates api_key → 200 OK

Why this matters

• Security: The /api/* bypass rule exposes Dawarich's entire API to the public internet without any reverse proxy protection. With Access Token headers, Pangolin validates every API request before it reaches Dawarich.
• Defense-in-depth: Two layers of authentication (Pangolin Access Token + Dawarich API key) instead of just one.
• No more bypass rules: Clean Pangolin configuration without having to carve out exceptions.
• Self-hosting best practice: Many self-hosters run apps behind authenticating proxies (Pangolin, Authelia, Authentik). Supporting custom headers makes Dawarich a better citizen in these setups.

What would need to change

Minimum viable change (Dawarich App)

The Dawarich iOS and Android apps are the most important piece — they should support configuring custom HTTP headers in their connection settings, so users can add the Pangolin Access Token headers. This is purely a client-side change and requires no server-side modifications.

Nice to have (Server-side)

• Display a "Custom Headers" section in account settings where users can define headers and see them alongside their API key
• Optionally validate a custom header on the server side (Option B)

Context

This is a common pain point for self-hosters running apps behind Pangolin. The same pattern applies to other apps like Immich, where users already configure P-Access-Token-Id and P-Access-Token headers in the mobile app to avoid bypass rules (see [fosrl/discussions#455](https://github.com/orgs/fosrl/discussions/455)).

Dawarich's privacy-first philosophy aligns perfectly with eliminating unnecessary auth bypass rules. This change would make Dawarich one of the best-integrated self-hosted apps for authenticated reverse proxy setups.

[jakobbjelver]

I second this. Many people are hosting their home labs behind tunnels/proxies and won't expose their services directly without some authentication. And mobile client apps cannot authenticate with browser auth flows. Adding support for Custom Headers when connecting to the server from the mobile app would be great.

The only way to access the mobile app, when not exposing Dawarich directly, is by using a VPN like Tailscale or Cloudflare One. In my experience, these drain a lot of battery and are troublesome having running all the time.

Do you think this is a valid idea @Freika ?

[Freika]

Can't promise you this right now but we may introduce this in the future

[lofiplays]

I would love to run dawarich in my homelab but this is a killer limitation at this point in development. If this is introduced im going to have another look at this project!

[eTSFX]

+1 extremely valuable for self hosters and being introduced more and more as standard for companion apps

[tgrecojr]

This is the one thing that is holding me back from using this software. My use case is similar to the original poster, but the Cloudflare version. I would like to add custom headers to the IOS app for Cloudflare service tokens (CF-Access-Client-Id, CF-Access-Client-Secret) in order to bypass API calls from the ios application, but still enforce identity on the main app through their zero trust tunnels. TY for your consideration.

[jolgen]

For the moment, and until this feature (hopefully) gets implemented, other client apps may be a suitable workaround for some. It's why I use OwnTracks (as it supports custom http headers).

[tgrecojr]

Thank you @jolgen . In checking out OwnTracks, it does support a custom HTTP header, but only a single one. It doesn't seem to support the multi-line needed to send multiple headers, which the reverse proxies need for ID and Secret. Were you able to achieve this in some way with the owntracks configuration?

[Yeeeetus]

Would also really like to see this implemented 👍