Added user-quota as server config
Description
user-quota config added for managing turn allocations counts per turn creds
Reference issue
This MR introduces user quota functionality to restrict the number of allocations per TURN credentials, similar to coturn's user-quota configuration. The implementation allows end users to set allocation limits per credential, preventing resource exhaustion attacks and unauthorized usage. This enhancement improves security posture by limiting potential abuse while providing feature parity with coturn's quota system. The quota configuration is integrated into the existing credential validation flow, ensuring seamless operation with minimal performance impact.
Codecov Report
:x: Patch coverage is 95.83333% with 2 lines in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 67.97%. Comparing base (a4a8111) to head (5775535).
:warning: Report is 21 commits behind head on master.
| Files with missing lines | Patch % | Lines |
|---|---|---|
| internal/allocation/allocation_manager.go | 96.15% | 1 Missing :warning: |
| internal/server/util.go | 83.33% | 1 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## master #464 +/- ##
==========================================
+ Coverage 67.43% 67.97% +0.54%
==========================================
Files 43 43
Lines 3083 3126 +43
==========================================
+ Hits 2079 2125 +46
+ Misses 843 840 -3
Partials 161 161
| Flag | Coverage Δ | |
|---|---|---|
| go | 67.97% <95.83%> (+0.54%) |
:arrow_up: |
| wasm | 26.07% <4.16%> (-0.34%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
@rg0now , would you able to review this change?
This functionality is also covered by #423, which is on top of the general event handler API proposed in #419. Can you please clarify the relation of this PR with those ones, if any?
In general, I'm not against merging PRs that implement useful functionality in piecemeal deltas instead of the larger PRs (like the event handler as of #419) which are always much more difficult to get merged. That being said, if there's any chance for the event handler API to get merged in a timely fashion then I'd drop this PR and go with the more generic approach in #423.
@rg0now , I am also looking for #423 MR to get merge , but this MR has more changes and open since nov 2024. I am not sure if this change can be merged sooner, hence in interim I am looking forward for this change.
Let me try to update #419 and #423 first, hopefully we can get those ones merges soon
@rg0now , the only concern is if #419, #423 gets delayed or blocked due to some reason, we should fast track this MR atleast.
I've rebased #419 and #423 on top of the latest master and we got an approval from @JoeTurki so hopefully both will be merged soon.
Thanks @rg0now , please follow up to get those MRs merged, accordingly I can update this MR.
both PRs finally got merged :)
@rg0now Should we release the next version as v4.1.0 or just v4.0.3? I'd lean toward bumping the minor version and going with v4.1.0.
@JoeTurki I don't have strong opinions on versioning, anything greater than the current will work...:-)
As per this PR: I think it would be extremely useful to re-implement this on top of #419 and #423 (just track the number of allocations per user via the OnAllocationCreated and OnAllocationDeleted callbacks) and turn it into an example, wdyt?
@JoeTurki I don't have strong opinions on versioning, anything greater than the current will work...:-)
Released as v4.1.0 :)