ThreeMammals/Ocelot

Claim-based rate limiting

Open

#1.587 geöffnet am 18. Juli 2022

Auf GitHub ansehen
 (8 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)C# (1.617 Forks)batch import
AuthenticationRate Limitingacceptedfeaturehelp wantedproposal

Repository-Metriken

Stars
 (8.137 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 10T 13h) (4 gemergte PRs in 30 T)

Beschreibung

New Feature

Extracting claims from the token and use as a Client ID in the rate limiting. Suggesting a new feature to implement the rate limiting based on the claims in the token.

Motivation for New Feature

Current rate limiting is based on the Client ID passed in the header from the request. There are chances that anyone can manipulate the request by updating headers and using APIs without any restriction.

So, instead of depending on the consumer to provide the Client ID in the header, we can use the claims from the token. Which is more secure and not modifiable. Considering this, a rate limit will be applicable for authenticated endpoints only.

Specifications

  • Version: 18.1.0
  • Platform: .NET 6

Contributor Guide

Research-Richtung
Beginnen Sie mit der Überprüfung der bestehenden Ratenbegrenzungs Middleware in Ocelot (wahrscheinlich im Ocelot Quellcode unter Middleware oder RateLimit). Suchen Sie nach der Stelle, an der ClientId derzeit aus Headern extrahiert wird. Untersuchen Sie dann die Authentifizierungs Middleware, um zu sehen, wie Token Ansprüche verfügbar gemacht werden. Das Ziel ist, optional einen Anspruch wie sub oder client id aus dem Token für die Ratenbegrenzung zu verwenden. Prüfen Sie die Kommentare im Issue auf Anleitungen der Maintainer oder verknüpfte PRs. Erwägen Sie, eine Konfigurationsoption hinzuzufügen, um zwischen Header basierter und Anspruch basierter Client ID zu wählen. Stellen Sie sicher, dass die Implementierung nur authentifizierte Endpunkte betrifft.
Tech Stack
csharp
Domain
backendapi
Issue Type
Funktion
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
5
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-2 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
C#.NETOcelotrate limiting
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
60