Sorry. After updating from 5.1.1 to 5.2.0 and enabling the new per-flag flood control (#3112986: Use flood control API in flag), anonymous users with the flag <flag_id> permission can no longer flag. The flag link is no longer clickable or usable for them. This still happens in 5.2.x and 5.3.x. Authenticated users (the more typical case) are not affected.
Since #3112986: Use flood control API in flag, Flag::actionAccess() combines the flag type access with FlagFloodControlService::access() for the flag action. When that returns forbidden, ActionLinkTypeBase::getAsFlagLink() renders no usable link.
For anonymous users, the flood identifier is built from the IP address only:
'anonymous:' . $request->getClientIp() . '-' . $flag_idThis leads to the following problems:
reverse_proxy configuration, getClientIp() returns the proxy IP for every visitor. With the default limit (10 per 3600 s), ten anonymous flaggings on the whole site block anonymous flagging for everyone for an hour. Visitors behind a shared NAT (offices, schools, mobile carriers) run into the same problem.max-age 0, but core's Internal Page Cache ignores max-age for anonymous responses. A page rendered while the limit was reached can keep serving the non-flaggable state after the window ends.The result is that anonymous flagging, which worked in 5.1.1, becomes effectively unusable once flood control is enabled on a flag.
flag <flag_id> and unflag <flag_id> permissions.$settings['reverse_proxy'] configured, or use a setup where all requests come from the same IP, as in many local Docker/DDEV setups.SELECT identifier, COUNT(*) FROM flood WHERE event = 'flag.flagging' GROUP BY identifier; shows one shared anonymous:<ip>-<flag_id> identifier.Expected: anonymous visitors are rate-limited individually, as far as possible, and the limit for one visitor does not lock out all others or get cached in pages.
Actual: all anonymous visitors are blocked after a few flaggings across the whole site.
reverse_proxy / reverse_proxy_addresses in settings.php correctly. This only helps with the proxy case, not with shared NAT.To be discussed. Options:
ip cache context on every flag link.Possibly a clarified description for the flood control settings on the flag form.
Possibly: FlagFloodControlService::createIdentifier() uses a different identifier for anonymous users.
None.
Issue summary prepared with the help of AI!
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
anybodySorry I missed that and tests don't seem to fully cover it. I'll now try to reprocue it in a failing test and prepare a fix!
Comment #3
anybodySeems I found the root cause:
FlagFloodControlService::createIdentifier()identifies anonymous users only by IP ('anonymous:' . getClientIp()). Behind a reverse proxy, load balancer, container network or shared NAT, every anonymous visitor therefore shares a single flood bucket.The flood check is also part of render-time access (
Flag::actionAccess('flag')→andIf()flood access). Once that shared bucket reaches the limit (default 10/hour),ActionLinkTypeBase::getAsFlagLink()renders nothing for all anonymous users. With a rolling window, busy sites lose anonymous flagging almost permanently.Reproduced with a new functional test: after anonymous visitor A reaches the limit, a different anonymous visitor B (new session, same IP) gets no flag link. The
floodtable shows one shared identifieranonymous:172.19.0.5-<flag_id>. Rendering and page caching are fine; the problem is only how anonymous users are identified.Proposed fix: identify anonymous users by Flag's existing anonymous session ID (
flag.session_id), and keep an IP-based limit only as a higher safety net against cookie-dropping.Comment #4
anybody#3636853: Provide a CAPTCHA integration point for (anonymous) flagging and unflagging will introduce a further safety net...
Comment #5
anybodyComment #6
anybodyComment #7
anybodyPushed a fix to both issue branches (5.3.x and 5.2.x), all tests green.
Changes
flag.session_id) instead of per IP, so visitors sharing an IP (reverse proxy, containers, NAT) no longer block each other.flood_control_ip_limit, default 50,0= off). Applies to anonymous users only, so deleting the session cookie doesn't get around flood control. Must be 0 or ≥ the per-user limit.max-age 0, so otherwise a denied page would be served to all anonymous visitors.flag_update_10302()sets the IP limit on existing flags tomax(50, flood_control_limit).Session behavior: viewing a page still doesn't start a session, and pages stay cacheable (page cache
HITverified). A session starts only at the first flagging. That flagging is counted even though Drupal starts the session lazily in that request.Tests
AnonymousFlagFloodTest(functional, with page cache): one visitor reaching the limit doesn't block others, no session on view, page cache hit, session lifecycle, IP limit, and the denied state isn't cached.FlagFloodControlTest(kernel): session separation, IP limit, IP limit ignored for authenticated users, defaults.FlagFloodTest: validation of the new setting.API / BC: no breaking changes under the BC policy.
FlagInterface::getFloodControlIpLimit()/setFloodControlIpLimit(). The interface has one implementation, like the flood methods added in 5.2.0.FlagFloodControlServicegets a new autowired constructor argument; service constructors are internal.createIdentifier()returns a session-based value for anonymous users.Since this adds a setting and an update hook, a minor release may be the better fit; maintainers' call. Release note: anonymous flood control is now per session plus per IP; run
drush updband export config.Please review.
Comment #10
anybodyOk we should add additional tests for views, it doesn't work there yet. In full display it works as expected. Also combined with the new captcha solution!
Comment #11
anybodyOkay evantually this is false alarm and was caused by a template override in our project. I'll investigate deeper!
Comment #12
anybodyClosing this one: the reported symptom was not caused by Flag.
flag--likes--card.html.twig) that unlinks the flag. In 5.1.1 that template was never used, because the view mode wasn't passed to flag links. #3626500: [regression] Restore the view mode of flag links restored that in 5.2.0, so view-mode template suggestions now take effect. Themes with view-mode flag templates should check them when updating to 5.2.x.reverse_proxyconfiguration.While debugging, I found a real, separate bug: a denied anonymous page can stay in the Internal Page Cache and hide flag links from all anonymous users. Follow-up: https://www.drupal.org/project/flag/issues/3638056. The MRs here can be closed.
Sorry for the trouble!