# DRF Throttling: Verwendung von "scope" – Vergleich von ScopedRateThrottle und UserRateThrottle‑Vererbung

In DRF gibt es zwei häufig genutzte Muster, wenn man scope‑basierte Throttling anwendet.

* **Muster A**: Erstellen einer eigenen Klasse, die `UserRateThrottle` (oder `SimpleRateThrottle`) erbt und dort einen **festen scope** definiert. Diese Klasse wird dann direkt in `throttle_classes` der View eingesetzt.
* **Muster B**: Registrieren von `ScopedRateThrottle` in `DEFAULT_THROTTLE_CLASSES` und in der View lediglich `throttle_scope = "login"` angeben.

Frage: "Gibt es letztlich keinen Unterschied?"

> **Wenn man nur einen einzelnen Ratenlimit‑Wert für "userID (oder nicht‑authentifizierte IP) + scope" festlegen möchte, sind die Resultate nahezu identisch.** Der Unterschied liegt jedoch in **Anwendungssicherheit, Erweiterbarkeit (mehrere Richtlinien/benutzerdefinierte Kriterien) und Code‑Struktur (Einstellungen vs. Code)**.

---

## Gemeinsam: Beide erzeugen einen Schlüssel aus "scope + (user ID oder IP)" {#sec-431a00e0f2d6}

* `ScopedRateThrottle` baut den Schlüssel aus `throttle_scope` + userID/IP und sucht den entsprechenden Wert in `DEFAULT_THROTTLE_RATES`.
* `UserRateThrottle` verwendet ebenfalls userID (authentifiziert) bzw. IP (nicht‑authentifiziert). Für mehrere Richtlinien empfiehlt DRF, die Klasse zu erben und unterschiedliche scopes zu setzen.

---

## Unterschied 1) Wo wird der scope definiert? – View‑Attribut vs. Klassen‑Attribut {#sec-d624b1b24a23}

### Muster A: Scope fest in der Klasse (explizit) {#sec-8806ad9d3f5f}

```python
from rest_framework.throttling import UserRateThrottle
from rest_framework.views import APIView

class CustomDomainSaveThrottle(UserRateThrottle):
    scope = "custom_domain_save"

class SaveCustomDomainView(APIView):
    throttle_classes = [CustomDomainSaveThrottle]
```

* Der scope ist **in der Klasse** festgelegt.
* Die View muss lediglich die Klasse referenzieren.
* Tippfehler im scope‑String werden reduziert – die Klassennamen dienen als Dokumentation.

### Muster B: Scope in der View, gemeinsamer Throttle (Einstellungen) {#sec-21174dce63ed}

```python
REST_FRAMEWORK = {
  "DEFAULT_THROTTLE_CLASSES": [
    "rest_framework.throttling.ScopedRateThrottle",
  ],
  "DEFAULT_THROTTLE_RATES": {
    "login": "5/min",
  }
}

from rest_framework.views import APIView

class LoginView(APIView):
    throttle_scope = "login"
```

* Der scope wird **direkt in der View** gesetzt.
* Der gemeinsame Throttle (`ScopedRateThrottle`) interpretiert den Scope und holt die Rate aus den Einstellungen.
* Der Code ist kompakter und die Richtlinien lassen sich zentral in den Einstellungen verwalten.

---

## Unterschied 2) Wer garantiert die Anwendung? – Globale Registrierung vs. View‑spezifische Montage {#sec-693e9b27f525}

### Punkt B (häufig missverstanden) {#sec-579edda7168e}

Selbst wenn `ScopedRateThrottle` in `DEFAULT_THROTTLE_CLASSES` registriert ist, **wird er nicht auf Views ohne `throttle_scope` angewendet.**

### Vorteil von Muster A {#sec-1d7d8c13bc83}

Man kann ohne globale Einstellungen gezielt **bestimmte Views** mit einem gewünschten Throttle ausstatten. Das ist praktisch, wenn die globalen Einstellungen nicht geändert werden dürfen oder nur ein Teil der API streng limitiert werden soll.

---

## Unterschied 3) Erweiterbarkeit: Mehr als ein einzelnes Limit – Muster A gewinnt {#sec-76818ce0201b}

Die beiden Muster sehen ähnlich aus, solange es nur **ein Scope und ein Limit pro View** gibt. Sobald man jedoch mehr als ein Limit benötigt, unterscheiden sie sich deutlich.

### 1) Mehrere Throttles (z. B. Burst + Sustained) {#sec-c0ea02305999}

DRF‑Dokumentation zeigt ein Beispiel, bei dem mehrere `UserRateThrottle`‑Klassen gleichzeitig verwendet werden.

```python
class Burst(UserRateThrottle):
    scope = "burst"

class Sustained(UserRateThrottle):
    scope = "sustained"

class SearchView(APIView):
    throttle_classes = [Burst, Sustained]
```

Mit `ScopedRateThrottle` lässt sich **nicht** einfach zwei unterschiedliche scopes für dieselbe View definieren – man braucht wieder eigene Klassen (oder eine eigene Implementierung).

### 2) Andere Kriterien als userID/IP {#sec-39de8e67072d}

`ScopedRateThrottle` arbeitet standardmäßig mit userID bzw. IP. In der Praxis tauchen jedoch häufig andere Anforderungen auf:

* Login: Limitierung nach **IP + Benutzername** (z. B. für Account‑Target‑Angriffe).
* Organisation/Teenant: Limitierung nach **tenant_id**.
* API‑Key: Limitierung pro Schlüssel.

Diese Szenarien erfordern eine Anpassung von `get_cache_key()` und führen daher zu einer **benutzerdefinierten Throttle‑Klasse** – also zu Muster A.

---

![Zwei Schlüssel, die eine API‑Verbindung öffnen](/media/editor_temp/6/e98f026a-a38e-43ca-8c86-fa7966dd3cdf.png)

## Was sollte man wählen? {#sec-1cf080d47909}

### Für die meisten "View‑spezifischen Rate‑Limits" → Muster B (ScopedRateThrottle) {#sec-924ae91c07d2}

* Minimaler Code
* Zentrale Verwaltung in den Einstellungen
* Nur Views mit `throttle_scope` werden limitiert

### Wenn eines der folgenden zutrifft → Muster A (Vererbung/benutzerdefinierte Klasse) {#sec-335f8d95a231}

* Mehrere Limits (z. B. Burst + Sustained) gleichzeitig auf einer View
* Nicht‑userID/IP‑Kriterien (z. B. IP + Username, tenant, API‑Key)
* Globale Einstellungen sollen nicht verändert werden, aber bestimmte Views müssen limitiert werden
* Die Klassennamen sollen als Dokumentation dienen

**Weiterführender Artikel:**

- [DRF Throttling vollständig beherrschen: Einstellungen, Anwendung, benutzerdefinierte Anleitung](/ko/whitedec/2026/1/26/drf-throttling-complete-guide/)