2.3 KiB
| title | date | description | url | type | mp-syndicate-to | tags | resources | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Setting up HTTP(S) and Firefly III with Caddy | 2023-01-02T12:38:40Z | banging my head against walls so that you don't have to | /2023/1/2/caddy-firefly | post |
|
|
|
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.
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.