ThreeMammals/Ocelot

Claim-based rate limiting

Ouverte

#1 587 ouverte le 18 juil. 2022

Voir sur GitHubGuide contributeur
 (8 commentaires) (0 réaction) (0 personne assignée)C# (1 617 forks)batch import
AuthenticationRate Limitingacceptedfeaturehelp wantedproposal

Métriques du dépôt

Stars
 (8 137 étoiles)
Métriques de merge PR
 (Merge moyen 44j 17h) (6 PRs mergées en 30 j)

Description

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

Guide contributeur

Direction de recherche
Commencez par examiner le middleware de limitation de débit existant dans Ocelot (probablement dans le code source d'Ocelot sous Middleware ou RateLimit). Cherchez où ClientId est actuellement extrait des en têtes. Ensuite, explorez le middleware d'authentification pour voir comment les revendications du jeton sont rendues disponibles. L'objectif est d'utiliser optionnellement une revendication comme sub ou client id du jeton pour la limitation de débit. Vérifiez les commentaires de l'issue pour toute orientation des mainteneurs ou PR liés. Envisagez d'ajouter une option de configuration pour choisir entre un ID client basé sur les en têtes ou sur les revendications. Assurez vous que l'implémentation n'affecte que les points de terminaison authentifiés.
Stack technique
csharp
Domaine
backendapi
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
5
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
C#.NETOcelotrate limiting
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
60