Requests that have variable cost? #318
Comments
|
Actually, I see that the underlying API has a This allows for different methods to have different costs, but I still don't see a way to customize the |
|
You're right - there's not and this is just an oversight. The api should have been: I'll tweak that and make a release soon. |
|
The cost callable will be evaluated after the request is complete, correct?
…On Sat, Mar 5, 2022, 5:17 PM Ali-Akber Saifee ***@***.***> wrote:
You're right - there's not and this is just an oversight. The api should
have been:
def limit(
....
cost: Union[int, Callable[[], int]]
I'll tweak that and make a release soon.
—
Reply to this email directly, view it on GitHub
<#318 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACULE2526OWLLWSGZIUL2SDU6QBQTANCNFSM5PU2XZXQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
No (in most cases) since the rate limit is evaluated and "hit" in the before request part of the request life cycle (since in most cases you are interested in the protecting the resource you are rate limiting). Having said that the requirement for conditional actions based on the actual response from the current request has come up often and there are a few ways you can "tweak" the default behaviour.
I realise both the above suggestions are a bit of a workaround (though perhaps 1 isn't that horrible if you squint a bit 😃 ) Lemme know if the combination of these would work for you ? |
|
Thank you for the ideas, let me do a bit of noodling and see how this would
work.
And thanks for the awesome library and the quick, helpful responses!
…On Sat, Mar 5, 2022, 6:03 PM Ali-Akber Saifee ***@***.***> wrote:
The cost callable will be evaluated after the request is complete, correct?
No (in most cases) since the rate limit is evaluated and "hit" in the
before request part of the request life cycle (since in most cases you are
interested in the protecting the resource you are rate limiting).
Having said that the requirement for conditional actions based on the
actual response from the current request has come up often and there are a
few ways you can "tweak" the default behaviour.
1.
by using the deduct_when
<https://flask-limiter.readthedocs.io/en/stable/recipes.html#customizing-rate-limits-based-on-response>
parameter which effectively turns a regular limit which is tested and
deducted from in the before request phase, to a limit that is tested in
before request (and if the requesting user has already exceeded your
resource is protected) and if not the deduction is performed in the after
request phase depending on the response from your deduct_when
callable. In this scenario the cost callable would be evaluated once
in the before request for the test, and once in the after request phase for
the deduction.
2.
doing the extra deduction completely manually. As of 2.1 there is a
[current_limits][
https://flask-limiter.readthedocs.io/en/stable/api.html#flask_limiter.Limiter.current_limits]
property available on the extension itself that you can access both during
the request and in the after request phase. You could potentially add your
own after_request hook and simple do the extra deductions (not great
because you'd be making extra requests to your rate limit backend).
I realise both the above suggestions are a bit of a workaround (though
perhaps 1 isn't that horrible if you squint a bit 😃 )
Lemme know if the combination of these would work for you ?
—
Reply to this email directly, view it on GitHub
<#318 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACULE25FOY4JOVURIQGJG2DU6QG5VANCNFSM5PU2XZXQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Aha, I think I understood the deduct_when solution.
The call that happens before I can just return 1, and the request will be
blocked or allowed.
Then the call that happens afterwards can return true and the cost call can
return the appropriate higher value.
How will I tell from within the cost callable whether it is a before or
after invocation?
…On Sat, Mar 5, 2022, 6:29 PM Miles ***@***.***> wrote:
Thank you for the ideas, let me do a bit of noodling and see how this
would work.
And thanks for the awesome library and the quick, helpful responses!
On Sat, Mar 5, 2022, 6:03 PM Ali-Akber Saifee ***@***.***>
wrote:
> The cost callable will be evaluated after the request is complete,
> correct?
>
> No (in most cases) since the rate limit is evaluated and "hit" in the
> before request part of the request life cycle (since in most cases you are
> interested in the protecting the resource you are rate limiting).
>
> Having said that the requirement for conditional actions based on the
> actual response from the current request has come up often and there are a
> few ways you can "tweak" the default behaviour.
>
> 1.
>
> by using the deduct_when
> <https://flask-limiter.readthedocs.io/en/stable/recipes.html#customizing-rate-limits-based-on-response>
> parameter which effectively turns a regular limit which is tested and
> deducted from in the before request phase, to a limit that is tested in
> before request (and if the requesting user has already exceeded your
> resource is protected) and if not the deduction is performed in the after
> request phase depending on the response from your deduct_when
> callable. In this scenario the cost callable would be evaluated once
> in the before request for the test, and once in the after request phase for
> the deduction.
> 2.
>
> doing the extra deduction completely manually. As of 2.1 there is a
> [current_limits][
> https://flask-limiter.readthedocs.io/en/stable/api.html#flask_limiter.Limiter.current_limits]
> property available on the extension itself that you can access both during
> the request and in the after request phase. You could potentially add your
> own after_request hook and simple do the extra deductions (not great
> because you'd be making extra requests to your rate limit backend).
>
> I realise both the above suggestions are a bit of a workaround (though
> perhaps 1 isn't that horrible if you squint a bit 😃 )
>
> Lemme know if the combination of these would work for you ?
>
> —
> Reply to this email directly, view it on GitHub
> <#318 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACULE25FOY4JOVURIQGJG2DU6QG5VANCNFSM5PU2XZXQ>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
|
This is embarrassing, looks like I don't know my way around my own code :D |
|
Thank you!
…On Sat, Mar 5, 2022, 7:14 PM Ali-Akber Saifee ***@***.***> wrote:
I've pushed a new release 2.2.0
<https://flask-limiter.readthedocs.io/en/stable/changelog.html#v2-2-0>
which allows using a function for cost
<https://flask-limiter.readthedocs.io/en/stable/api.html#flask_limiter.Limiter.limit.params.cost>.
Should help with the experimentation.
—
Reply to this email directly, view it on GitHub
<#318 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACULE27ZQ7ISBNRENZEVEVDU6QPIHANCNFSM5PU2XZXQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Let me know if this works and if we can close this issue? |
|
Yes, I should be able to verify and reply tomorrow. It seems likely to work.
…On Mon, Mar 7, 2022, 6:40 AM Ali-Akber Saifee ***@***.***> wrote:
Let me know if this works and if we can close this issue?
—
Reply to this email directly, view it on GitHub
<#318 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACULE22XA364S2AGVV7KETTU6YIOZANCNFSM5PU2XZXQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
It works great. I verified that I can access the metadata I need about the request handling from within the Thank you! |
Hey guys, I'm curious whether flask-limiter could help when requests have variable cost. For instance, can I count a single request against the limit with some multiplier based on the content of the request?
If not, do you all have any thoughts on how to help with this type or metering?
The text was updated successfully, but these errors were encountered: