Wie wir unseren $ _SESSION loswerden?

Question

Unser Projekt enthält einige Daten in einem einzigen $_SESSION['app']. Es gibt ein "Haupt" -Objekt, das ungefähr 10 öffentliche Instanzen anderer Objekte enthält, die innerhalb des Codes verwendet werden können. Tatsächlich wird nur einer von ihnen regelmäßig verwendet ($_SESSION['app']->login->getuserId()) und zwei von ihnen werden nur 4-5 mal insgesamt verwendet.

Da wir neben unserem Projekt eine RESTful-API erstellt haben, möchten wir einige der Funktionen unserer Projekte innerhalb der API verwenden und müssen daher die Sitzung, die in vielen Methoden in fast allen Objekten verwendet wird, loswerden Auf lange Sicht wollen wir komplett auf die REST-konforme Kommunikation zwischen Client und Server umsteigen.

Da wir ein kleines Team sind, können wir es uns nicht leisten, den gesamten Code auf einmal zu refaktorieren, aber wir müssen Schritt für Schritt vorgehen, ohne den Code in der Zwischenzeit zu brechen.

Mein erster Versuch ist die Umwandlung der Session-Objekt in ein Singleton wie folgt aus:

class Main { 

    private static $main = null; 

    public static function getInstance() { 
    self::$main = $_SESSION['app'] ?? self::$main ?? new Main(); 
    return self::$main; 
    } 

    public function __construct { 
    // ... 
    } 
} 

Auf diese Weise seit einiger Zeit konnten wir die Instanziierung von $ _SESSION [ ‚App‘] lassen, wie es ist und später Entfernen Sie die Sitzung vollständig in einem kleinen Arbeitsschritt. Mein Versuch funktioniert soweit, aber es verschiebt nur das konzeptionelle Problem, das ich mit der Klasse Main habe.

Auch ich habe gelesen, dass die Verwendung des Singleton-Patterns in den meisten Fällen eine schlechte Idee ist und die Argumente für diese Meinung verstehen. In unserem Projekt verwenden wir noch keine Komponententests, aber ich möchte das bald für meinen Code verwenden.

Also, was eine bessere und zuverlässigere Art und Weise unseres $_SESSION -variable loszuwerden und in einer Art und Weise, wie die userID Daten handhaben wäre, dass sie von überall her zugegriffen werden konnten, so dass wir am Ende eine RESTful Authentifizierung haben statt einer Sitzung?

Answer 1

Dies ist die Art und Weise, wie ich sehe, dass:

Wenn wir für eine Sekunde vorstellen, dass Sie ein System von Ihrem Traum mit RESTful API haben, dann wahrscheinlich die Kommunikation zwischen Clients und einem Sever verlässt sich auf " access_token "Lösung, was bedeutet, dass es eine Klasse oder Klassen geben wird, die einen Benutzer autorisieren und Benutzerberechtigungen überprüfen.

Diese Lösung wird irgendwie während des Bootstrapping-Prozesses verwendet, sollte aber vorzugsweise isoliert und entkoppelt sein und somit durch ein Abhängigkeits-Injektionsparadigma implementiert werden. Das gibt Ihnen sofort die Möglichkeit, eine Implementierung durch eine andere zu ersetzen (genialer Unit-Testing-Bonus, eh!)

Die erste Implementierung könnte jedoch vollständig auf den aktuellen Sitzungen aufbauen. Um es einfach zu machen, können Sie mit einer "plain" ersetzen $_SESSION['app'] mit etwas wie Di::getDefault()->getSession()->get('app') oder vielleicht Di::getDefault()->getAuthorizedUser()->getApp() und dann einfach immer Ihre Funktionalität auf dem Kopf wachsen.