Soften the brute force protection on shared links with password or without

[GVLLIFESTYLE]

The protection block at to many requests pretty fast.
Especially on public links it would be nice to be able to soften that or to exclude special public links from the protection.
Especially if they have a password.

So yes after a few password attempts it can block the ip. But it my case even if the password is typed in correct it block after too many requests / downloads.

[DanScharon]

yes, currently the bruteforce protection is too quick in regards to public shares. I know this is meant to block trying to guess possible public URLs, but you just need 20 user who click on an expired share and their whole subnet is getting blocked

[joshtrichards]

But it my case even if the password is typed in correct it block after too many requests / downloads.

That part would sound like a bug. What makes you think this is brute force protection? Are you seeing log entries indicating brute force protecting is kicking in? (it logs at the INFO level aka 1).

their whole subnet is getting blocked

Just to clarify, brute force protection doesn't block based on subnet, but only individual IP addresses.

Multiple users won't impact each other, unless they're all coming from the same source IP address (which can happen admittedly in a remote larger office setting if using NAT).

Especially on public links it would be nice to be able to soften that or to exclude special public links from the protection.
Especially if they have a password.

Since we control the random token generation, I suppose there could be case made here.

[DanScharon]

their whole subnet is getting blocked

Just to clarify, brute force protection doesn't block based on subnet, but only individual IP addresses.

Multiple users won't impact each other, unless they're all coming from the same source IP address (which can happen admittedly in a remote larger office setting if using NAT).

That's true for IPv4 but not for IPv6. In that case the whole /64 prefix is put on block. The reasoning I remember behind this decision was, that a device can easily pick another address within the same /64 prefix. Has this changed in the meantime?