[TwigBridge][TwigBundle] Add rate_limit() Twig function
#61439
Conversation
0a587d7 to
8ec3f64
Compare
rate_limit() Twig functionrate_limit() Twig function
ea4ed11 to
a76a0cf
Compare
a76a0cf to
bc4d692
Compare
|
Thoughts: displaying a feature doesn't mean one is going to use it. But using this in template will do this: consume rate-limiter tokens while the feature has not been used yet. I'd be fine with a helper that decides whether some token is consumed. But consuming should be done when actually consuming a feature (eg in the rate-limited API call / form handler) |
|
Hi 👋 Thanks a lot for your feedback! I completely agree with your point. Ideally, we should separate the check from the consumption of rate-limiter tokens. That said, there's currently a small limitation: the If you're okay with it, I'd be happy to work on a new method (e.g., For Symfony 8.0, this could involve updating the interface directly, and for 7.4, I could add the method only to the current implementations (without modifying the interface, to keep it BC). Once that's in place, I can update this Twig feature to follow your suggestion and support something like: {% set can_access = rate_limit('anonymous_api', expression('request.getClientIp()')) %}This would simply check access without consuming any tokens or perhaps we could add an optional parameter to control whether tokens should be consumed. 🤔 What do you think? Thanks again for the suggestion! ❤️ |
|
/cc @wouterj maybe? WDYT? |
Summary
This PR introduces a new
rate_limit()Twig function to enable rate limiting logic directly within Twig templates.Usage Examples
{% set limit = rate_limit('anonymous_api', expression('request.getClientIp()')) %} {% if limit %} <p>You have access to this limited feature.</p> {% else %} <p>Rate limit exceeded.</p> {% endif %}You can also use static keys:
{% set limit = rate_limit('anonymous_api', 'custom_key', 5) %}Motivation
The motivation behind this feature is to provide a simple, declarative way to apply rate limiting to specific sections of a template.
A typical use case is gating a single expensive or high-demand feature (e.g. AI calls, feedback buttons, real-time components), while still rendering the rest of the page.
For example:
This approach allows template authors to apply rate limiting surgically, exactly where it’s needed, while keeping other parts of the page fully accessible.