Halten Sie ältere LoopBack -APIs auf dem neuesten Stand, ohne eine Neuprogrammierung des Frameworks erzwingen zu müssen

LoopBack 4 ist die aktiv weiterentwickelte Produktreihe, liegt jedoch weit hinter den hier behandelten älteren Versionen zurück. LoopBack 2 erreichte im April 2019 das Ende seines Lebenszyklus, LoopBack 3 folgte im Dezember 2020 – und genau dort befindet sich noch immer ein Großteil des LoopBack-Codes in der Produktion. Dank des ELS von TuxCare erhalten die abgedeckten LoopBack-Versionen weiterhin Sicherheitsupdates.

Ersetzen Sie das abgedeckte LoopBack-Paket und die betroffenen Abhängigkeiten durch von TuxCare gepflegte Entsprechungen, anstatt auf einem neueren Framework neu zu kompilieren. Die Einrichtung umfasst drei Zeilen in der Datei .npmrc, eine Änderung in der Datei package.json, die Ihre Abhängigkeit auf den ELS-Build verweist, sowie den Befehl „npm install“. Modelle, Remote-Methoden, Startskripte und ACLs bleiben unverändert.

ELS deckt derzeit die Versionen LoopBack 1.10.0 und 2.42.0 ab. Bei beiden handelt es sich um ältere Versionen, für die keine reguläre Wartung durch den Upstream-Entwickler mehr erfolgt. Falls Ihre Anwendung eine andere Version verwendet, einschließlich aller Versionen der 3.x-Reihe, wenden Sie sich bitte an TuxCare, um die Abdeckung zu besprechen.

Ja. Eine ältere LoopBack-Anwendung übernimmt Risiken aus dem Framework und aus allen darunter liegenden Komponenten. ELS kann abgedeckte Abhängigkeiten über npm-Overrides auf von TuxCare verwaltete Pakete umleiten, sodass die Behebung nicht auf das LoopBack-Paket der obersten Ebene beschränkt ist.

Ja. ELS wurde für Anwendungen entwickelt, bei denen ein sauberer Umstieg auf ein neueres Framework nicht möglich ist. Die unterstützten Pakete werden über npm bereitgestellt, wodurch Teams den bestehenden Abhängigkeitsgraphen anpassen können, ohne die bereits verwendete Architektur aufgeben zu müssen.

Es sind keine Änderungen am Anwendungscode erforderlich. Sie konfigurieren das npm-kompatible TuxCare-Repository, ersetzen die Referenzen auf die abgedeckten Pakete, aktualisieren die Abhängigkeiten und führen wie gewohnt Tests durch. Dabei geht es darum, das LoopBack-Verhalten beizubehalten, das Ihre API bereits erwartet.

Ja. ELS-Pakete werden über npm aus dem npm-kompatiblen TuxCare-Repository bezogen, sodass dieselbe Registry-Konfiguration sowohl bei Container-Builds als auch in jedem CI/CD-Workflow funktioniert, der Abhängigkeiten bereits mit npm installiert. Das Token wird aus der Datei .npmrc Ihres Projekts gelesen.

ELS wurde entwickelt, um die Anforderungen zur Behebung von Sicherheitslücken im Rahmen von Rahmenwerken wie SOC 2, PCI DSS, HIPAA, NIS2, DORA und CRA zu erfüllen. Ein vertraglich festgelegter Patching-Prozess bietet Sicherheits- und Audit-Teams eine dokumentierte Lösung für Software, die ansonsten nicht unterstützt wird.

Die Migration ist nach wie vor ein sinnvolles langfristiges Ziel, da der Wechsel zwischen verschiedenen LoopBack-Generationen echte Änderungen an der Anwendung mit sich bringt. ELS gibt Teams die Möglichkeit, zunächst Patches zu installieren und erst dann zu migrieren, wenn die API, das Datenmodell, die Integrationen und die Testabdeckung bereit sind.