ChrispyBacon-dev/DockFlare v1.8.4

DockFlare v1.8.4 - Path Routing, Service Types, Access Policies & UI Polish!

on GitHub

DockFlare v1.8.1 - Path Routing, Service Types, Access Policies & UI Polish!

DockFlare v1.8.1 is here, bringing highly requested Path-Based Routing, versatile Extended Service Type Support, more powerful Manual Rule creation with Access Policy support, and several UI and backend improvements for a smoother and more robust experience!

New Features & Major Enhancements:

1. Path-Based Routing for Ingress Rules:

   • Define specific URL paths on your hostnames to route to different backend services or parts of an application.
   • Docker Labels: Specify URL paths using your-label-prefix.path=/your-service-path or your-label-prefix.{index}.path=/your-service-path.
     • Example: Expose myapp.example.com/api by setting cloudflare.tunnel.hostname=myapp.example.com and cloudflare.tunnel.path=/api.
     • You can define multiple distinct hostnames, each with its own optional path, from a single Docker container using indexed labels (e.g., cloudflare.tunnel.0.hostname, cloudflare.tunnel.0.path, cloudflare.tunnel.1.hostname, cloudflare.tunnel.1.path).
     • Note on Docker Label Path Routing: Currently, if a single Docker container attempts to define multiple different paths for the exact same hostname via its labels, only the last processed path definition for that hostname will be active. Subsequent path definitions for the same hostname from the same container will overwrite previous ones.
       • Example: Labels for app.example.com/api and app.example.com/ui on the same container would result in only one of these path rules being applied (the one with the highest index or processed last).
       • To route multiple paths on the same hostname to different services using Docker labels, consider using separate containers for each service/path combination.
   • Manual Rules UI: The "Add New Manual Ingress Rule" dialog now includes an optional "Path" field.
     • The displayed "/" in the UI is automatically prepended; users just type the path segment (e.g., "app").
     • You can create multiple manual rules for the same hostname with different paths, each pointing to different services.
   • Functionality: Cloudflare Tunnel ingress rules are configured with these paths. Requests matching hostname + path are forwarded, appending the matched path and subsequent segments to the origin service URL.
     • Example: Public myapp.com/api/users with service http://backend:3000 and path /api in DockFlare routes to http://backend:3000/api/users.
   • UI Display: The "Managed Ingress Rules" table now includes a "Path" column, showing "(root)" if no path is set. Clickable hostname links correctly include the path.

2. Extended Service Type Support:

   • DockFlare now robustly supports a wider range of service types beyond just HTTP/S, aligning with Cloudflare Tunnel capabilities. Supported types include: http, https, tcp, ssh, rdp, and http_status (for returning a specific HTTP status code).
   • Docker Labels: Specify the service type directly in your existing service label. DockFlare will parse the prefix to determine the type.
     • cloudflare.tunnel.service=http://localservice:80
     • cloudflare.tunnel.service=https://securelocal:443
     • cloudflare.tunnel.service=tcp://gameserver:25565
     • cloudflare.tunnel.service=ssh://internalhost:22
     • cloudflare.tunnel.service=rdp://desktop:3389
     • cloudflare.tunnel.service=http_status:404
   • Manual Rules UI: The "Add New Manual Ingress Rule" dialog features a clear "Service Type" dropdown. The "Service Address" input field dynamically guides the user based on the selected type (e.g., showing tcp:// prefix, expecting host:port or just a status code).

3. Enhanced Manual Rule Creation with Access Policy Support:

   • Direct Access Policy Assignment: When adding a new manual ingress rule via the UI, you can now directly assign a Cloudflare Access Policy:
     • None (Public - No App)
     • Bypass (Public App - creates a Cloudflare Access App with a bypass policy)
     • Authenticate by Email (creates a Cloudflare Access App requiring email authentication)
     • Use Default *.tld Policy (relies on an existing TLD wildcard policy, no app created by DockFlare for this rule)
   • A conditional "Allowed Email(s) or Domain(s)" field appears when "Authenticate by Email" is selected.
   • This provides upfront security configuration for manually exposed services.

4. UI Improvements for Manual Rule Modal:

   • The "Add New Manual Ingress Rule" dialog has been restructured for better clarity, grouping "Public Hostname," "Service," and "Access Policy" fields, inspired by the Cloudflare dashboard layout.
   • Increased modal width for better readability and field layout on larger screens.

Fixes & Other Enhancements:

• State Management & Backend Logic:
  • state.json correctly stores/loads path, hostname_for_dns (for manual rules), and new access policy attributes for manual rules.
  • update_cloudflare_config in tunnel_manager.py now correctly uses the base FQDN hostname and path when constructing ingress rules for the Cloudflare API.
  • Logic for identifying DockFlare-managed rules in the Cloudflare API config now correctly considers paths for uniqueness.
  • Enhanced sorting of ingress rules for Cloudflare API updates to ensure consistent ordering.
  • Improved conditional deletion of DNS records and Access Applications when manual rules are removed, preventing premature deletion if resources are shared by other path-based rules on the same base hostname.
• UI Display & Links:
  • Corrected display of hostnames for Docker-originated rules in the UI after path-handling changes.
  • Links in the "Managed Ingress Rules" table now consistently use https:// (or the current scheme of the DockFlare UI) for external links.
  • Fixed a Jinja2 template syntax error related to quote escaping in onsubmit confirm dialogs.
  • Resolved an issue where SVG icons (e.g., link icon in DNS records list) could render overly large by ensuring Tailwind CSS classes for sizing are correctly applied.
• Service URL Validation:
  • Stricter validation for HTTP/S service URLs (from labels and UI) now disallows paths within the service definition itself (e.g., http://host:port/api is invalid; path should be specified separately). For other types like TCP/SSH/RDP, the host:port format is enforced. http_status expects a status code.

Impact for Users:

• Increased Flexibility & Granularity: Path-based routing, extended service types, and direct access policy assignment offer significantly more control.
• Improved User Experience: Clearer UI for adding rules, more accurate displays, and corrected link behaviors.
• Enhanced Stability: Backend fixes ensure more reliable interaction with the Cloudflare API and state management.
• No Change to Existing Root Rules: Rules without a specified path continue to function as before.

To Use New Features:

• Path-Based Routing (Docker): Add {prefix}.path label. Remember the note above regarding multiple paths for the same hostname from a single container.
• Extended Service Types (Docker): Prefix your service URL in the {prefix}.service label (e.g., tcp://host:port, http_status:503).
• Manual Rules (Path, Service Type, Access Policy): Use the updated "Add New Manual Ingress Rule" modal in the Web UI.