Wie wir den Composer-Auth-Proxy gebaut haben, der unsere Magento-Module bereitstellt

Jedes eTechFlow-Modul wird über Composer aus einem privaten Repository unter repo.etechflow.com installiert. Das Repository ist durch kundenindividuelle Anmeldeinformationen geschützt, die einer bestimmten Lizenzberechtigung zugeordnet sind. Dieser Beitrag beschreibt die Technik hinter diesem Zugang: den Auth-Proxy, den Lebenszyklus der Anmeldeinformationen und die Ausfallmodi, die wir entworfen haben.

Das Problem, das wir lösen mussten

Wenn ein Kunde ein Magento-Modul von uns kauft, muss er zwei Dinge tun, um es zu installieren. Zuerst muss er unser Composer-Repository zu seiner composer.json hinzufügen. Zweitens muss er sich mit Anmeldeinformationen authentifizieren, die nur für ihn funktionieren.

Die meisten Anbieter von Magento-Modulen lösen dies mit gemeinsamen anbietergebundenen Anmeldeinformationen (jeder, der von Amasty kauft, verwendet ein Set von Amasty-Anmeldeinformationen) oder mit emailbasierten Anmeldeinformationen (deine Kontomail und Bestellnummer). Beide haben ihre Probleme. Gemeinsame Anmeldeinformationen können nicht widerrufen werden, wenn eine Lizenz zurückerstattet wird. Email-Anmeldeinformationen können durch Screenshots und Fehlerberichte durchsickern.

Wir benötigten Anmeldeinformationen, die lizenzgebunden, widerrufbar, rotierbar und prüfbar sind.

Die Architektur

Drei Komponenten kümmern sich um die Authentifizierung bei jeder Installation.

Komponente 1: der Auth-Proxy. Ein kleiner Node-Dienst vor dem eigentlichen Composer-Repository. Jede Anfrage an repo.etechflow.com trifft zuerst den Proxy. Der Proxy liest die HTTP-Basisauthentifizierungsanmeldeinformationen aus der Anfrage, überprüft sie in unserer Lizenzdatenbank und entscheidet, ob er die Anfrage weiterleitet.

Komponente 2: die Lizenzdatenbank. Speichert Anmeldeinformationen, die mit der Lizenz-ID verknüpft sind. Jede Zeile enthält die Kunden-ID, den Modul-Slug, den sie gekauft haben, das Anmeldeinformationen-Paar (Benutzername plus bcrypt-hashiertes Passwort), das Ausgabedatum, optionales Ablaufdatum, Widerrufsstatus und den letzten Validierungszeitstempel.

Komponente 3: das Prüfprotokoll. Jeder Authentifizierungsversuch (Erfolg oder Misserfolg) schreibt eine Zeile mit IP-Adresse, Zeitstempel, angeforderten Paket und übereinstimmender Lizenz-ID. Das Prüfprotokoll ist abfragbar und bildet die Grundlage für Warnungen bei verdächtigen Aktivitäten.

Der vollständige Anfragefluss bei einem composer require etechflow/some-module:

1. Composer sendet HTTP-Basisauthentifizierung an den Auth-Proxy.
2. Der Proxy überprüft das Anmeldeinformationen-Paar in der Lizenzdatenbank.
3. Wenn gültig und nicht widerrufen, leitet der Proxy die Anfrage an das interne Composer-Registry weiter.
4. Das interne Registry gibt das angeforderte Paket zurück.
5. Der Proxy protokolliert den Erfolg und gibt die Antwort an Composer zurück.

Die gesamte Latenzüberlastung: unter 50 Millisekunden pro Paketabruf. Eine typische Composer-Installation ruft 1 bis 3 Pakete von uns ab, sodass die Überlastung für den Kunden unsichtbar ist.

Der Lebenszyklus der Anmeldeinformationen

Eine Anmeldeinformation wird zum Zeitpunkt des Modulkaufs generiert. Die Kunden-E-Mail erhält das Anmeldeinformationen-Paar plus Installationsanweisungen sofort. Die Anmeldeinformationen sind an die Lizenz-ID gebunden, was bedeutet, dass sie atomar widerrufen werden, wenn der Kunde eine Rückerstattung beantragt (30-tägiges Rückerstattungsfenster).

Nach 12 Monaten laufen die Anmeldeinformationen ab und wir senden eine Erneuerungsanmeldeinformation. Die alte Anmeldeinformation funktioniert 90 Tage lang während des Übergangsfensters weiter, sodass die Kunden ihr auth.json ohne Eile aktualisieren können.

Wenn ein Kunde einen Verdacht auf Anmeldeinformationsleck hat (in ein öffentliches Repository eingegeben, in einem Fehlerbericht abgebildet), kann er die Rotation über sein Kontodashboard durchführen. Die Rotation widerruft die alte Anmeldeinformation sofort und gibt eine neue aus.

Der Ausfallmodus, um den wir herumgebaut haben

Das größte Risiko dieser Architektur ist die Unverfügbarkeit des Auth-Proxys. Wenn repo.etechflow.com ausfällt, scheitert jeder Kunde, der versucht, ein Modul zu installieren oder zu aktualisieren. Wir haben drei Schutzschichten:

Geografische Redundanz. Der Auth-Proxy läuft in zwei Regionen mit aktiv-aktivem Routing. Ein regionaler Ausfall wechselt innerhalb von 60 Sekunden.

Datenbank-Lese-Replikate. Die Anmeldeinformationsabfragen erfolgen gegen Lese-Replikate mit einer Replikationsverzögerung von 10 Sekunden. Schreibvorgänge (neue Anmeldeinformationen, Widerrufe) treffen das Primärsystem. Lesezugriffe überstehen einen Primärausfall.

Sanfte Degradierung. Wenn die Datenbank vollständig unerreichbar ist, greift der Proxy auf einen 60-minütigen Anmeldeinformationen-Cache zurück, der die letzte erfolgreiche Abfrage speichert. Kunden, die während dieses Fensters installieren, haben weiterhin Erfolg. Neue Modulkäufe pausieren, bis die Datenbank wiederhergestellt ist.

Der sanfte Degradierungsweg wurde seit dem Start dreimal ausgelöst. Jedes Mal berichteten die Kunden von keinen Problemen.

Was wir den Kunden veröffentlichen

Kunden sehen die Architektur indirekt durch drei Oberflächen.

Der auth.json-Ausschnitt in ihrer Kauf-E-Mail sagt ihnen genau, was sie zu ihrem Shop hinzufügen müssen. Das Format ist standardmäßige HTTP-Basisauthentifizierung in der von Composer erwarteten Struktur, sodass jeder Composer-versierte Ingenieur es lesen kann.

Das Kontodashboard zeigt ihnen alle aktiven Anmeldeinformationen, wann jede ausgestellt wurde, und einen Ein-Klick-Rotationsbutton. Wir zeigen den Passwortwert nach der Erstellung nicht an; die Rotation generiert ein neues.

Das Prüfprotokoll ist standardmäßig nur intern. Kunden können einen Export ihrer eigenen Anmeldeaktivitäten für Sicherheitsüberprüfungen anfordern.

Was wir anders machen würden

Zwei Designentscheidungen, die wir überdenken würden, wenn wir von vorne anfangen.

Wir würden HTTP-Bearer-Token anstelle von Basisauthentifizierung verwenden. Composer unterstützt seit einigen Jahren Bearer-Token und sie sind einfacher zu widerrufen, ohne die Erwartungen des Installateurs zu brechen. Wir haben zu Beginn die Basisauthentifizierung gewählt, weil sie mit älteren Composer-Versionen funktioniert; die älteren Versionen sind jetzt selten genug, dass wir umsteigen könnten.

Wir würden den OAuth-Gerätefluss für die erstmalige Installation in Betracht ziehen. Heute muss der Kunde die Anmeldeinformationen manuell in auth.json einfügen oder einen Composer-Konfigurationsbefehl ausführen. Der OAuth-Gerätefluss würde es ermöglichen, dass die Installation aus der Browsersitzung des Kunden genehmigt wird. Fügt Infrastruktur hinzu, senkt aber die Hürden für die erste Installation.

Warum das für das Magento-Ökosystem wichtig ist

Die meisten Anbieter von Magento-Modulen haben keine ordentliche Anmeldeinformationsinfrastruktur aufgebaut. Das gängige Muster (gemeinsame Anmeldeinformationen, emailgebundener Zugriff, kein Prüfprotokoll) schafft echte Sicherheitslücken. Wenn ein Magento-Shop durch ein Drittanbieter-Modul kompromittiert wird, ist die Prüfspur zurück zur Vertriebsinfrastruktur des Anbieters normalerweise leer, weil keine Infrastruktur existierte, um zu protokollieren.

Wenn Sie Magento-Modul-Anbieter bewerten, fragen Sie sie, wie ihre Composer-Authentifizierung funktioniert. Die Antwort zeigt, wie ernst sie die Sicherheit der Lieferkette nehmen.

Verwandt

• Composer-Auth für private Magento-Repositories behandelt die Einrichtung auf der Kundenseite.
• Käuferleitfaden für Magento-Erweiterungen behandelt die Bewertungskriterien für Anbieter.