Berechtigungen und Feature-Flags, gesteuert von der Lizenz

Die meisten Lizenzierungs-Tutorials enden bei einem Boolean: Ist die Lizenz gültig oder nicht? Das beantwortet, ob der Kunde Ihre Software überhaupt ausführen darf. Es beantwortet nicht die Frage, die Ihr Produkt tatsächlich hundertmal am Tag stellt: Was darf genau dieser Kunde tun? Darf er SSO nutzen? Nach PDF exportieren? Sein elftes Projekt anlegen? Das ist die Aufgabe von Berechtigungen (Entitlements): benannte Fähigkeiten, die an eine Lizenz gebunden und von Ihrer App lokal gelesen werden.

Die Form einer Berechtigung

Eine Berechtigung ist eines von zwei Dingen:

• Ein Feature-Flag — eine boolesche Fähigkeit, benannt nach dem, was sie freischaltet: sso, export, api-access, white-label.
• Ein numerisches Limit — eine Obergrenze, die die App durchsetzt: max-projects, max-seats, api-calls-per-day.

Diese liegen als Vorlage auf einer Stufe (etwa Free, Pro, Enterprise). Beim Ausstellen einer Lizenz auf einer Stufe erbt sie die Berechtigungen dieser Stufe, und sie werden in die signierte Lizenz eingebettet, die der Kunde aktiviert. Eine Pro-Lizenz könnte { sso: false, export: true, "max-projects": 25 } tragen; Enterprise, { sso: true, export: true, "max-projects": -1 } (mit -1 für unbegrenzt).

Berechtigungen in Ihrer App lesen

Nach der Aktivierung cached das SDK eine signierte Lease und parst ihre Berechtigungen. Sie lesen sie synchron, ohne Netzaufruf:

var client = KeyrightClient.Initialize(options);
var info = await client.ActivateAsync(licenseKey);   // once; the lease is then cached

// Later, anywhere in your app:
if (client.IsEnabled("sso"))
    EnableSingleSignOn();

int maxProjects = client.GetLimit("max-projects", fallback: 1);

Zwei Eigenschaften machen das sicher. Erstens fällt es in den gesperrten Zustand: ein unbekanntes Flag liefert false, und ein fehlendes Limit liefert den Fallback, den Sie angeben — Sie übergeben also den konservativsten Wert, nie einen optimistischen. Zweitens ist es offline: die Berechtigungsvorlage ist Teil der signierten Lease, verifiziert gegen den öffentlichen Schlüssel, den Sie zur Build-Zeit einbetten. Ändern Sie einen Wert, passt die Signatur nicht mehr, sodass die Prüfung fehlschlägt, statt still zu viel zu gewähren.

Durchsetzen an der Grenze der Fähigkeit, nicht nur in der Oberfläche

Einen ausgegrauten „Exportieren”-Button zu verstecken ist gute UX, aber keine Durchsetzung — jeder kann die Methode dahinter aufrufen. Setzen Sie die echte Prüfung an die Grenze der Fähigkeit selbst: die Funktion, die die Aktion ausführt.

public Report ExportToPdf(ExportOptions options)
{
    if (!_license.IsEnabled("export"))
        throw new FeatureNotLicensedException("export");

    return _renderer.Render(options);
}

Numerische Limits werden im Moment der Erstellung durchgesetzt, wo Sie den aktuellen Zählerstand bereits kennen:

public Project CreateProject(string name)
{
    int limit = _license.GetLimit("max-projects", fallback: 1);
    if (limit >= 0 && _store.ProjectCount() >= limit)
        throw new LimitReachedException("max-projects", limit);

    return _store.Add(name);
}

Beachten Sie die Schranke limit >= 0: ein negatives Limit (-1) bedeutet unbegrenzt, also wird die Obergrenze übersprungen. Einen einzigen Sentinel für „unbegrenzt” zu wählen und ihn konsequent anzuwenden, hält jede Aufrufstelle ehrlich.

Ändern, was eine Stufe freischaltet, ohne eine Version zu veröffentlichen

Weil Berechtigungen serverseitig auf der Stufe definiert sind, ist Neu-Packaging eine Konfigurationsänderung, keine Codeänderung. Fügen Sie api-access zur Pro-Stufe hinzu, und jede Pro-Lizenz übernimmt es bei ihrer nächsten Aktualisierung: keine neue Version, keine neu ausgestellten Schlüssel, keine Kundenaktion. Starten Sie ein neues Add-on, indem Sie ein einziges Flag auf den Stufen umlegen, die es haben sollen. Das ist der eigentliche Gewinn des Fähigkeit-statt-Plan-Modells: Ihr Packaging und Ihr Release-Takt werden unabhängig.

Es macht auch Preisexperimente billig. Verschieben Sie export für ein Quartal von Enterprise auf Pro, messen Sie die Conversion, verschieben Sie es zurück — alles, ohne die Anwendung anzufassen, die Ihre Kunden ausführen.

Entwurfsregeln, die gut altern

• Benennen Sie Flags nach Fähigkeit, nicht nach Plan. export, nicht pro-feature. Wenn Sie Pro später in Pro und Team aufteilen, muss sich nichts in Ihrem Code ändern.
• Machen Sie Limits numerisch und fallen Sie auf den Boden zurück. Der Fallback, den Sie an GetLimit übergeben, sollte der Wert der niedrigsten Stufe sein, damit eine fehlende oder fehlerhafte Berechtigung sauber degradiert, statt alles freizuschalten.
• Verwenden Sie nie den Namen eines ausgemusterten Flags erneut. Wenn Sie legacy-sync entfernen, recyceln Sie den Schlüssel nicht für etwas anderes: alte gecachte Leases können ihn noch tragen. Behandeln Sie Berechtigungsschlüssel als rein additives Vokabular.
• Entscheiden Sie pro Fähigkeit, was der Ablauf bewirkt. Wenn eine Lizenz in ihr Kulanzfenster rutscht, lassen manche Produkte Nur-Lese-Funktionen aktiv und sperren nur das Schreiben; andere halten ganz an. Kodieren Sie diese Richtlinie dort, wo Sie das Flag lesen, nicht verstreut in der Oberfläche.

Berechtigungen verwandeln eine Lizenz von einem Tor in einen Vertrag, den Ihr Code abfragen kann. Sobald Funktionen und Limits aus einer signierten Vorlage fließen, hören „diesen Kunden hochstufen” und „diese Funktion an alle Pro-Kunden ausliefern” auf, Engineering-Aufgaben zu sein, und werden zu einem Schalter — genau dort, wo diese Kontrolle hingehört.