Update:
Fixed my problem by using on404 and adding custom path prefix to the links for those special accounts/ips.
Not closing the ticket myself in case Ed would like to do something with it.
Describe the bug
I just wanted to bypass filekeys for certain users/IP addresses using on403 handlers and found out that it doesn't work.
If user have get permission and tries to access filekey-protected file without supplying filekey they get 403 unconditionally without processing by on403 handler.
Setting g:* in volume access settings disables on403 in that volume because now anyone can_get and on403 is never called.
To Reproduce
copyparty.conf
[accounts]
u1:p1
u2:p2
[/]
/w
accs:
A: u1
g: *
flags:
fk: 8
on403: /handlers/hello.py
/handlers/hello.py
def main(cli, vn, rem):
cli.log("hello, make sure you see this line in the log")
# unfortunately you don't
if cli.uname == "u2":
return "allow"
return ""
Then authorize as u2 and open link to some file in / volume without filekey.
Expected behavior
on403 is called when user with get-permission tries to access a file without providing filekey
Returning "allow" allows the user to download the file.
Server details (if you are using docker/podman)
docker under Debian 13
copyparty | copyparty v1.20.21-2-g04ad29d9 "sftp is fine too" (2026-08-21)
copyparty | CPython v3.14.5 on Linux64 6.12.100 [GCC 15.2.0]
copyparty | sqlite 3.53.2*1 | jinja 3.1.6 | pyftpd 1.5.10 | tftp 0.4.0 | miko 4.0.0
The rest of the stack
Caddy + caddycrowdsec bouncer
Update:
Fixed my problem by using on404 and adding custom path prefix to the links for those special accounts/ips.
Not closing the ticket myself in case Ed would like to do something with it.
Describe the bug
I just wanted to bypass filekeys for certain users/IP addresses using on403 handlers and found out that it doesn't work.
If user have get permission and tries to access filekey-protected file without supplying filekey they get 403 unconditionally without processing by on403 handler.
Setting
g:*in volume access settings disables on403 in that volume because now anyonecan_getand on403 is never called.To Reproduce
copyparty.conf
/handlers/hello.py
Then authorize as u2 and open link to some file in
/volume without filekey.Expected behavior
on403 is called when user with get-permission tries to access a file without providing filekey
Returning "allow" allows the user to download the file.
Server details (if you are using docker/podman)
docker under Debian 13
The rest of the stack
Caddy + caddycrowdsec bouncer