nicht angemeldet
Moin!
- Das Login als solches sollte als Singleton ausgeführt werden.
Negativ.
"Singleton" ist das einzige Pattern, das nennenswerten Bekanntheitsgrad erlangt hat, deshalb wird es von allen halbwissenden OOP-Programmierern als der heilige Gral erkannt und an allen möglichen und unmöglichen Stellen umgesetzt.
Dummerweise handelt man sich dadurch einige sehr negative Eigenschaften ein, die man bei genauerer Betrachtung nicht haben will:
a) Global State im Objekt: Eine neue Instanz des Objektes ist nicht neu, sondern exakt das alte, schon bisher verwendete Objekt - wenn es denn vorher schon mal verwendet wurde. Es hat also evtl. schon vom Initialzustand abweichende Inhalte, und insbesondere ändert die Nutzung des "anderen" Objekts auch dieses Objekt. Sowas ist schwierig zu debuggen.
b) Sehr eingeschränkte Testbarkeit aus demselben Grund.
c) Singletons sind in den meisten Fällen eigentlich gar nicht notwendig für das, was erreicht werden soll.
Insbesondere die globalen Eigenschaften
ini_set('session.use_only_cookies', '1');
ini_set('session.use_trans_sid', '0');im Konstruktor der Klasse zu verwursten, halte ich für bedenklich.
Definitiv ja.
- Die Klasse sollte beim Login auch überprüfen, ob Cookies vom Client akzeptiert werden und alternativ Basic Authentication anbieten.
Funktioniert nur, wenn man den Client zu zwei Requests veranlasst, und zwar für jeden User, ohne wirklichen Mehrwert zu schaffen. Absolut verzichtbar.
- Mit fehlen hier Methoden für unterschiedliche Protection-Grade und die klare Aussage, ob es ein Login-Check pro Session oder ein Login-Check pro Request oder sogar ein Login-Check pro diskreter Anforderung (auf Methodenebene) sein soll.
Es geht um den Login, also die Authentifizierung, nicht um Autorisierung. Das ist ein komplett anderes Gebiet bzw. die deutlich größere Rückseite dieser selben Medaille.
- Sven Rautenberg