Getting macOS webDAV working when behind Caddy and Authelia

[freddyheppell]

Note

Due to a longstanding bug in Apple's shitty webDAV implementation, connections to Copyparty will hang for 90s until a patch in Copyparty (8e046fb) is released

I've got Copyparty behind a Caddy reverse proxy using forward_auth to Authelia, and Copyparty set up to use its auth headers as an IdP. This all works pretty straightforwardly, the issue is getting WebDAV connections to work from Finder.

A bit of background first: auth in WebDAV is done through HTTP Basic login where the credentials get put in the Authorization header. Authelia supports Basic auth, but doesn't advertise this to clients (otherwise your browser would prompt for Basic auth credentials instead of redirecting to login). Most sensible clients (e.g. Cyberduck) send the Authorization header immediately, so Authelia checks them and won't redirect to login. However Finder's webDAV implementation seems to always attempt to connect without credentials first, and will only retry with the Authorization header if it gets the correct request for Basic auth credentials back. Finder considers Authelia returning a redirect to the login page an unrecoverable error and thus never tries again with the Authorization header.

The solution is to detect requests from Finder, intercept them before forward_auth and return an error advertising basic auth. Finder will see this, retry the request with an Authorization header, and it will all (hopefully) work.

You probably also want to set the scheme_basic_cache_lifespan setting on your authz endpoint. Each request with an Authorization header counts as a new username/password login attempt, so Authelia (rightfully) takes a non-trivial amount of time (~500ms) to hash the password, and if using will hit your LDAP server each time. Finder makes an excessive number of requests per operation, so this has quite an impact. This config setting causes Authelia to remember that a set of Basic auth credentials is valid/invalid for a period of time, reducing the impact of this. I'd set it to something low like 5-10s, which will cover a single burst of requests but not stick around for too long.

copyparty.example.org {
	@webdavAuthHint {
		# Match the two different UAs used by Finder 
		header User-Agent *WebDAVLib*
		header User-Agent *WebDAVFS*
		# header User-Agent *OtherMisbehavingClient*
		# Only match requests without Basic Auth header
		header !Authorization
	}

	# Caddy usually interprets `forward_auth` before `handle`, this forces the order
	# Be VERY careful as anything you add before `forward_auth` in this block will not be auth protected  
	route {
		# If Finder is requesting without auth, send an error to force it
		handle @webdavAuthHint {
			# Realm name can be anything btw
			header WWW-Authenticate `Basic realm="WebDAV"`
			respond 401
		}
		forward_auth {
			# Whatever you'd usually have here, see Authelia's docs
		}
		reverse_proxy copyparty:3923
	}
}

---

I developed this fix by looking at requests to a local instance of Copyparty and Wiresharking the loopback interface. If you encounter another WebDAV client that is misbehaving, try it against a locally running instance of Copyparty - if it works then the issue is probably the auth proxy. Check the requests in Wireshark and see if it's: a) sending an initial request without Authorization header and b) if it has a User Agent you can match against. So long as the UAs don't match a human web browser, it won't have any impact on non-webDAV requests.