brainsteam.co.uk/brainsteam/content/posts/2023/01/02/caddy-firefly/index.md

2.4 KiB

date description mp-syndicate-to post_meta preview resources tags title type url
2023-01-02 12:38:40+00:00 banging my head against walls so that you don't have to
https://brid.gy/publish/mastodon
https://brid.gy/publish/twitter
date
/social/351001d2bf2de16ca093c33940fcf974e10227492a3a5ca920d36d712ea9b1e4.png
name src
feature images/insecure.png
foss
software
devops
Setting up HTTP(S) and Firefly III with Caddy posts /2023/1/2/caddy-firefly

Today I'm experimenting with Firefly III the brilliant, FOSS budgeting app from James Cole 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

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. 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.