Comment on Expose only the share links of a private service with caddy
UltraBlack@lemmy.world 2 weeks ago
But… Why not just filter out anything that doesn’t regex match a key and them forward that request to the destination? An invalid share will just produce a 404 there
litchralee@sh.itjust.works 2 weeks ago
In a nutshell, doing it this way adds robustness when – not if – the destination software changes its behavior, inadvertently or not. It’s very similar to software assertions: if this assumption stops holding, then we want to know ASAP because it means subsequent logic is no longer valid.
In the Immich case, the author writes:
Suppose the author updates their Immich instance but missed a remark in the release notes that share keys will be using a different hash algorithm. That’s a mistake with their upgrade procedure, sure, but it’d be ideal if such mistakes were detected sooner than later. Without the check for link validity, the only log that would record the now-invalid share links would be in Immich logs. But with this additional check, there is also a log at Caddy. More visibility, combined with an existing alerting regime, means errors and mistakes are captured earlier.
At first glance, it might seem like both approaches still result in a 404 for the user, which suggests neither approach is really “robust”. But one is a near-silent failure yet the other gives a loud, unmistakable signal that something is broken, meaning it can be addressed. Phrased another way, the signal-to-noise ratio of an assert fail is very strong.