DockFlare v3.0.3: Building Access the Way It Should Be

[ChrispyBacon-dev]

Hey everyone,

I’m excited to share this update with you. This release has been a real labor of love, focused on solving the same pain points that led me to build DockFlare in the first place.

It’s a longer read, but worth it: not just what changed, but why it changed.

---

Identity Provider Management

This is the big one I’ve wanted for a long time: manage OAuth/OIDC Identity Providers (IdPs) directly inside DockFlare, no more jumping between dashboards.

What’s New

• Full IdP management: Add, edit, test, and delete Identity Providers (Google, Azure AD, GitHub, Okta, or generic OIDC) directly from DockFlare.
• Friendly names: Use human-readable labels like google-main or github-dev. DockFlare automatically maps them to Cloudflare UUIDs.
• One-click Cloudflare sync: Import existing IdPs with auto-generated friendly names.
• Built-in testing: Verify OAuth flows before production rollout.
• Brand-accurate icons: Instantly recognize each provider.
• System protection: Prevent accidental deletion of critical providers like one-time PIN.

---

Security by Design: Email Restrictions Required

By default, Cloudflare allows any Google account when using "Google" as an IdP, even personal ones.
DockFlare now enforces secure defaults: you must specify allowed emails or domains (admin@example.com, @company.com).

Both UI and API validations ensure you cannot create insecure configurations by accident.

“When using Identity Providers, you must specify allowed email addresses to prevent unauthorized access.”

---

Integration with Access Groups

Identity Providers now tie neatly into Access Groups:

• Choose one or more IdPs
• Specify allowed emails or domains
• Users must authenticate via the IdP and match the allowlist
• Both conditions must pass for access to be granted

---

Public vs Authenticated Access Modes

Previously, DockFlare mixed Cloudflare’s bypass and allow modes in confusing ways.
This release introduces a clean separation.

Public Access Mode (bypass)

• No authentication required; ideal for public sites or marketing pages
• Supports geo-blocking (for example, block high-risk countries)
• Visitors from allowed countries access directly, no login

Authenticated Access Mode (allow)

• Authentication required via email/domain or IdP
• Perfect for internal dashboards or private apps
• Geo restrictions stack on top of authentication

Why it matters: DockFlare now aligns perfectly with Cloudflare’s intended behavior, clean, predictable, and secure.

---

Zone Default Policies & Performance

Wildcard Zone Protection

A new section on the Access Policies page displays all DNS zones and their wildcard protection status. With one click, create a *.yourdomain.com policy to protect all subdomains even future ones.

This serves as a safety net: every subdomain gets a default protection policy automatically.

---

Migration to Reusable Access Policies

Summary:
DockFlare now creates reusable Access Policies in Cloudflare, replacing older inline policies. This change dramatically improves maintainability, sync accuracy, and scalability.

The Old Way (Inline Policies)

Originally, DockFlare embedded policies directly in each Access Application. It worked, but:

• Rules were duplicated everywhere.

• Maintenance was painful (e.g., update an email in 10 places).

• No centralized overview.

• Policy drift between DockFlare and Cloudflare.

The New Way (Reusable Policies)

Reusable policies scale far better, especially with upcoming DockFlare Agent Swarm mode, where multiple agents report services to a master node. With reusable policies:

• Create once, use everywhere – Apply one policy to many services.

• Single source of truth – Edit once, update everywhere instantly.

• Bi-directional sync – Cloudflare ↔ DockFlare stay aligned.

• Cleaner dashboards – Cloudflare Access view makes sense again.

• Swarm-ready – Centralized management for multi-agent deployments.

In short: reusable policies are how DockFlare should work at scale. Inline rules served early simplicity; reusable rules bring long-term reliability.

---

UI / UX Improvements

• New Identity Providers section with table view and sync button
• Two-tab Access Policy modal separating Public vs Authenticated modes
• TomSelect dropdowns for multi-select IdPs
• Better feedback and validation for security rules
• Unified styling across Dashboard and Access Policies
• Updated documentation links and OAuth setup guides

Backend Architecture

• New idp_manager.py with full CRUD via Cloudflare API
• Friendly-name to UUID mapping
• Persistent IdP metadata storage
• Access Groups now support a public_mode flag
• Public mode uses bypass; Authenticated mode uses allow
• Legacy block policies automatically converted to deny
• Async zone policy loading

Bug Fixes

• Fixed: public groups incorrectly using allow
• Fixed: simplified country blocking logic
• Fixed: reusable policies preserve all decisions (bypass, allow, deny)
• Fixed: deprecated field JS errors and dropdown overflow
• Fixed: IdP modal close behavior

---

API Token Update Required

Add one new permission to your Cloudflare API token for IdP management:

• Account:Access: Organizations, Identity Providers, and Groups:Edit

Without it, IdP creation or sync will fail (existing features still work).
See: [Prerequisites]

---

Security Testing and Validation

A full audit of all 99 application endpoints was performed for authentication, CSRF, injection, and authorization.

✅ All routes secured (100%)
✅ Strong CSRF protection
✅ XSS, path traversal, and SQL injection mitigated
✅ Sessions managed safely with no leaks detected

Full reports:

• Security Assessment Report
• Security Fix Plan
• Comprehensive Test Results

---

Important: “Disable Password Login” Setting

This feature is intended to avoid double authentication when DockFlare is already behind an enforced SSO gateway.

Risks when enabled:

⚠️ All API endpoints become unauthenticated.

⚠️ Containers on the same Docker network can bypass Cloudflare Access entirely.

⚠️ The app assumes security is handled elsewhere — dangerous without proper isolation.

Example:

Internet → Cloudflare Access (Protected) → DockFlare ✅
         ↓
Docker Network → Other Container → DockFlare API (Unprotected) ❌

Recommended approach:

1. Use local DockFlare credentials for simplicity, or
2. Configure OAuth/OIDC providers (Google, GitHub, Azure AD, etc.) for secure SSO.

Both options maintain proper authentication while preserving convenience.

Bottom line: Unless your network isolation is airtight, keep password login enabled and use OAuth for SSO.

---

Breaking Changes?

None. Existing setups continue to work.
DockFlare automatically migrates your groups to reusable policies on next sync.
Manual Cloudflare edits will sync back correctly.

---

Why This Update Matters

As a daily DockFlare user, I wanted to fix the things that frustrated me most:

“I want to use my Google account for login, but setup in Cloudflare is tedious.”
“I want my portfolio site public, but still block some countries.”

Identity Provider management and access-mode separation directly solve these.
No more dashboard switching. No more unnecessary authentication prompts.
DockFlare now aligns perfectly with how Cloudflare designed these features, flexible, secure, and practical.

---

Shout-outs and Credits

A huge thank-you to the community for helping shape this release with testing, feedback, and sharp insights:

• @solipsist01 – detailed beta testing and feedback on issue [FEATURE REQUEST / reusable policies #250]
• @kernel-sanders – great observations on access rule logic and issue [Security Issue: Using "Blocked Countries" allows any user from a non-blocked country to access the application #261]
• @sidbena – helpful suggestions and testing feedback on issue [Migrate from legacy to reusable access policies #83]
• @johntdyer – excellent input on access handling and usability in issue [Trouble w/ Google Auth setup #259]

Your contributions directly improved DockFlare’s development. 🙌

---

Final Thoughts

DockFlare is still a solo-developer passion project, something I genuinely love building.
If you find bugs or have ideas, please open a GitHub issue. Your feedback drives DockFlare’s evolution.

The IdP feature alone took about 80% of this release’s development time, from OAuth flow debugging to security hardening, but it was worth it.

Thank you to everyone using DockFlare and supporting its growth.

Next up:

• Migration assistant for legacy policies
• Policy conflict detection
• More granular access controls
• DockFlare Agent Swarm Mode (in active development)

Stay tuned, and happy tunneling!
Chris

---

Documentation Updates

The in-app help system and Markdown docs are updated for v3.0.3:

• [Identity Providers]
• [Prerequisites]
• [OAuth Provider Setup]

---

Full Changelog

For a detailed list of all changes, see the full changelog on GitHub:
CHANGELOG.md

Note: The project site (dockflare.app/docs) will update soon. For now, use the in-app help or Markdown files.

---

This discussion was created from the release DockFlare v3.0.3: Building Access the Way It Should Be.

[ChrispyBacon-dev]

Well, it appears that the used by service label for the policy is only visible on the public bypass policy. I follow up with a hotfix for this issue. The backend is functioning correctly, but the web UI is affected.

[ChrispyBacon-dev]

The update broke the path creation with introduction of reusable policies. eg. when you run a container with:

labels:
      dockflare.enable: "true"
      dockflare.hostname: "dockflare.domain.com"
      dockflare.service: "http://dockflare:5000"
      dockflare.access.group: "idp-blocker"
      
     -- OAuth Callback Path (Bypass Access Policy) --
      dockflare.0.hostname: "dockflare.domain.com"
      dockflare.0.path: "/auth/google/callback"
      dockflare.0.service: "http://dockflare:5000"
      dockflare.0.access.group: "public-default-bypass"

the second Application for the path is not created and it falls back to bypass. looking into it now for a hotfix.

[ChrispyBacon-dev]

Hotfixes v3.0.3

[v3.0.3] - 2025-10-07

Hotfix

• Access Policy Path Regression: Restored indexed label support for Cloudflare Access applications so path-specific rules (e.g., dockflare.0.path=/auth/google/callback) once again create distinct Access Apps linked to their reusable policies. Fixes broken policy sync introduced with the reusable policy migration in v3.0.3.
• Access Policy Usage Display: Corrected the “Used by these services” list so manual rules assigned to an Access Group appear alongside Docker/Agent-managed services, with paths shown when applicable.