Feature Request: Support for Cloudflare Access Token Authentication #5
Description
Summary
Add support for header-based authentication using Cloudflare Access tokens when connecting to a Firefly III instance hosted behind Cloudflare Tunnels.
⸻
Current Behavior
Currently, the custom node requires the Firefly III instance to be publicly accessible. Users hosting behind Cloudflare Tunnels must expose their instance to the internet, which undermines security and bypasses the benefits of Cloudflare Zero Trust.
⸻
Expected Behavior
The node should allow users to configure Cloudflare Access Client ID and Client Secret (or a bearer token) as part of the credential settings. These values should then be sent as custom headers with every API request.
⸻
Suggested Implementation
• Extend credential schema to support two optional fields:
• CF-Access-Client-Id
• CF-Access-Client-Secret
• Modify request logic to include these values in headers when defined.
• Default behavior remains unchanged if fields are not configured.
⸻
Benefits
• Enables users to keep Firefly III private and secured behind Cloudflare Zero Trust, without exposing it publicly.
• Enhances alignment with modern Zero Trust security models.
• Improves usability and adoption for privacy-focused deployments.
⸻
Example Header Authentication
CF-Access-Client-Id: <client_id>
CF-Access-Client-Secret: <client_secret>