tju-yxq opened a new issue, #3045: URL: https://github.com/apache/rocketmq-dashboard/issues/3045
## Problem The in-memory login limiter has two fail-open paths: 1. `recordFailure` starts a new failure window whenever the current state has `lockedUntilMillis != 0`. A request that passed `checkAllowed` just before another request created the lock can therefore finish later, call `recordFailure`, and replace the active lock with a one-failure unlocked state. 2. When the exact username map reaches `MAX_TRACKED_USERNAMES`, failures for every new username are ignored. Filling the map with distinct decoy names therefore leaves an untracked target username with no failure counter or lockout. Both cases are reproducible with the small-capacity test constructor. Five failures lock `operator`, but recording one more in-flight failure makes it allowed again. Separately, filling a two-entry tracker with decoys lets `operator` fail repeatedly without ever receiving a 429. ## Expected behavior - an active lock must remain in force until its lock duration expires, including when older in-flight attempts finish; - the limiter must keep a strict memory bound without disabling protection for usernames that arrive after the exact tracker is full; - expiration and successful-login reset behavior should remain deterministic; - capacity fallback should be bounded and should limit collision impact rather than applying one global lock to every untracked username. This is a correctness follow-up to the state bound introduced in #2400; it does not remove that memory bound. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
