You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Rate limiting (fail2ban) is usually used to prevent brute force auth attacks against a server. Wish offers both authentication and ratelimiting, but seems to call the auth handler first and then only calls the ratelimiter middleware if auth succeeds. Calling the rate limiter first produces the desired effect of preventing brute force auth attacks.
The order doesn't matter. The WithMiddleware writes to an array, but WithPasswordAuth (and the other auth methods) each write to a different struct variable inside the Server struct, which are processed before the Middleware.
Describe the bug
Rate limiting (fail2ban) is usually used to prevent brute force auth attacks against a server. Wish offers both authentication and ratelimiting, but seems to call the auth handler first and then only calls the ratelimiter middleware if auth succeeds. Calling the rate limiter first produces the desired effect of preventing brute force auth attacks.
To Reproduce
In the above server, auth is always called - regardless of rate limits, and the ratelimiter Middleware is only called if auth succeeds (returns true).
Expected behavior
Rate limiting should happen before auth, perhaps via
s.ConnCallback
instead of middleware.The text was updated successfully, but these errors were encountered: