configuring firefly with caddy
continuous-integration/drone/push Build is passing Details

This commit is contained in:
James Ravenscroft 2023-01-02 12:42:18 +00:00
parent 837c2e3db2
commit 6efca876aa
2 changed files with 38 additions and 0 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 24 KiB

View File

@ -0,0 +1,38 @@
---
title: "Caddy Firefly"
date: 2023-01-02T12:38:40Z
description: banging my head against walls so that you don't have to
url: /2023/1/2/caddy-firefly
type: post
mp-syndicate-to:
- https://brid.gy/publish/mastodon
- https://brid.gy/publish/twitter
tags:
- foss
- software
- devops
resources:
- name: feature
src: images/insecure.png
---
## Setting up HTTP(S) and Firefly III with Caddy
Today I'm experimenting with Firefly III [the brilliant, FOSS budgeting app from James Cole](https://github.com/firefly-iii/firefly-iii/) which I'm hoping will be a YNAB killer for me.
### The Issue
The app is running on a Raspberry Pi and there's a Caddy reverse proxy with SSL etc enabled running on my internet-facing server. I've been banging my head against the wall a bit because when I loaded the app, some of the content was being rendered via insecure http links which the app seems to have rendered.
![a screenshot warning the user that the site is insecure](images/insecure.png)
This meant that I couldn't register (and shouldn't because someone could be snooping on the unencrypted POST request).
### Fixing The Problem
I went to the documentation and tried messing with the `APP_URL` environment variable which the docs tell you not to bother with because it doesn't do anything useful. As expected, it didn't do anything useful.
I did a little bit of digging and it looks like Laravel, the framework that Firefly III is built on top of can detect whether or not it should render HTTPS links via the `X-Forwarded-Proto` header which is set automatically by caddy to tell it that the original connection was made over HTTPS (even if the connection between caddy and firefly is not encrypted because they're on the same machine etc). I spent a long time trying to work out why this wasn't enough and playing with manually overriding this header in my caddy file.
Then, I found [this](https://firefly-iii.readthedocs.io/en/latest/support/faq.html#i-can-t-seem-to-get-https-working-with-caddy). By default Firefly does not trust incoming connections from other downstream HTTP proxies (which is a good default because you could have a situation where a man-in-the-middle manipulates this value). We can set the value to `**` which means trust anything but a more secure option is to use the IP address of the machine that is running caddy.