• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

Objekt superglobal machen

F

freakXHTML

Mitglied
Hallo zusammen,
in meiner Klasse habe ich "Benutzername" und "Passwort" als Attribut. Da ich jedoch meine Klasse in verschiedenen Dateien nutze, muss ich stets neue Instanzen der Klasse erstellen. Dann bringen mir die Attribute nichts mehr, weil nur das eine Objekt den Inhalt dieser beiden Attribute kennt. Also arbeite ich ich Sessions und Cookies. Das funktioniert auch soweit, doch ich frage mich, ob es eine Möglichkeit gibt, ein Objekt superglobal zu machen, sodass ich auch in anderen Dateien darauf zugreifen kann.

Oder soll ich etwa ein Objekt in eine Session packen?

Vielen Dank
lg, freakXHTML
 
Ehrlichgesagt ist die Fragestellung ein Vergleich von Äpfeln und Birnen.

Da ich jedoch meine Klasse in verschiedenen Dateien nutze, muss ich stets neue Instanzen der Klasse erstellen.
Zum Vergrößern anklicken....

Das ergibt keinen Sinn, es sei denn, mit "verschiedenen Dateien" sind verschiedene HTTP-Requests gemeint.

Dann bringen mir die Attribute nichts mehr, weil nur das eine Objekt den Inhalt dieser beiden Attribute kennt. Also arbeite ich ich Sessions und Cookies.
Zum Vergrößern anklicken....

Die Argumentation empfinde ich nicht als nachvollziehbar. "Sessions" und "superglobal" haben (im Sinne des Ausgangsposts) nichts miteinander zu tun.

Ich nehme an, es geht dir darum, die Werte "Username" und "Passwort" über mehrere Requests hinweg zu behalten? Dazu ist in erster Linie interessant, wie und wo diese Werte serverseitig abgelegt sind (etwa in einer Datenbank). Natürlich wäre es möglich, sie in Cookies oder Sessions zu schreiben, aber das wird gemeinhin als schlechter Stil angesehen.
 
Ich sehe es nicht als Problem an Objekte in Sessions zu serialisieren, nicht umsonst gibt es __sleep und __wakeup. Das hat Geschwindigkeits- und Einfachheitsvorteile. Er sollte natürlich nur ausgewählte Objekte dort speichern, deren Daten sinnvoll über einen Request hinweg gespeichert werden sollten. Der Rest wird gecached.

Wenn er sowas wie Superglobal meint, sucht er sicherlich eine Registry.
 
Ich meinte das Abspeichern etwa des Passworts in einer Session-Datei (oder einem Cookie). Dazu besteht prinzipiell keine Notwendigkeit. Die User-ID und/oder irgendein Hash, der mit der Datenbank abgeglichen werden kann, sind ausreichend. Das Abspeichern von Userprofil-Daten in Sessions führt zudem nur zu Synchronisationsproblemen, falls diese Daten editiert werden, während die Session aktiv ist.

Gegen Serialisierung von Objekten in Sessions habe ich generell auch nichts.

Edit: Der Vollständigkeit halber: Die sinnvolle Vorgeheinsweise, etwa den Login-Status eines Nutzers in einer Session zu speichern, ist meiner Meinung nach, die User-ID in die Session zu schreiben (wenn ungleich Null, dann als Nutzer mit entsprechender ID eingeloggt) und entsprechende zusätzliche daten (etwa Username) bei jedem Request anhand der User-ID neu aus der Datenbank (bzw. persistent storage) auszulesen.
 
Zuletzt bearbeitet:
Ich ging einfach davon aus, das er das Passwort nicht als einfachen Text in die Datenbank ablegt. Sensible Daten (neben dem Passwort) wirst du immer in Session-Dateien haben, deshalb gibt es mit Suhosin, welches die Session-Dateien verschlüsselt.

Wenn man die Sessiondaten editiert sollte dieses Script einfach das neue Login-Objekt in die Session serialisieren. Sychronisationsproblem behoben.

Die Datenbank abzufragen wäre zu mindestens langsamer, sofern hier nicht gecached wird; was bei sich relativ wenig ändernden Daten wie Userdaten sicherlich eine gute Idee ist.
 
Das Caching dürfte/könnte beim Datenbanksystem über den Query Cache laufen, da die Anfrage per Request dieselbe ist. Ich hab's aber nie gebenchmarkt, ob Datenbankzugriff in dem Fall signifikant langsamer ist als Session-Zugriff. (Vermutlich schon langsamer.)

Ja, das Synchronisations-"Problem" ist sicherlich lösbar und bei halbwegs ordentlicher Programmierung auch kein großer Aufwand. *schulterzuck* Ich will da jetzt nicht großartig gegen argumentieren, zumal ich auch keine Argumente hätte. Bisschen redundant ist es halt schon, wenn dieselben Daten noch mal in der Datenbank stehen und quasi an zwei stellen "persistent" (gut, das trifft es nicht ganz) gespeichert werden, aber meinetwegen.

@freakXHTML: Entschuldige bitte das Offtopic. :) Weiter Erläuterungen von dir zum Thema wären vielleicht gut.
 
Ob schneller oder nicht hängt vom Umfang der Daten ab (sprich wie gross das File wird)
Kleiner Dateiabfragen sind definitiv schneller als ein Connect zur Datenbank, es sei denn die Datenbank ist permanent beschäftigt und der Daemon schläft gerade nicht (Cache nehme ich von der Aussage mal aus)

Das Lesen eines CSV-Files mit ca 1500 Zeilen kann schneller gehen als eine vergleichbare Datenbank-Abfrage (also connect, SQL-Statement senden und Speicherung des Ergebnisses in einem Array)

Ich bin übrigens ein Verfechter von Userdaten in Dateien, weil man sich auch einloggen kann, wenn z.B die Datenbank-Verbindungen mal defekt oder verlorengegangen sind. Reparaturoptionen sind heute in guten CMS Systemen ja nichts neues. Was nützen mir die Reparatur-Tools, wenn ich mich nicht authentifizieren kann.
 
Wenn du grundsätzlich gegen Redundanz bist, wäre Caching jedenfalls keine Option. ;)

@sysop:
Wenn dann aber bitte die Userdaten via Sqlite speichern, dann kann ich wenigstens meinen Adapter wechseln, wenn ich feststelle dass Sqlite damit überlastet ist.
 
Ich nutze gerne z.B .htuserID und mache mir den .htaccess-Schutz zu Nutze.
Wo und Wie ist dann ja auch Nebensache, Hauptsache, man kommt ins System. Fahre aber gut mit der Einstellung, und Cachen kann ich Dateien auch.
 
Hallo zusammen,
ich arbeite sehr viel mit Datenbanken, doch meiner Ansicht nach sind manchmal Cookies und Session absolut notwendig, um auch mit gutem Stil zu arbeiten. Ich habe neulich ein Loginscript geschrieben und falls ein Benutzer dauerhaft eingeloggt bleiben soll, müssen Cookies gesetzt werden. In diese schreibe ich dann einen Hash des Kennworts und den Benutzername rein. Was ist daran schlechter Stil? Die Cookies vergleiche ich dann mit der Datenbank.

Vielen Dank
lg, freakXHTML
 
Dass Benutzername und Passwort über den Cookie bekannt sind und deswegen gestohlen werden können z.B. durch Cross-Site-Scripting. In der Session deshalb, weil diese ebenfalls gestohlen werden können, wenn jemand Zugriff auf die Session-Dateien hat.

Edit: gut die Session-ID im Cookie kann auch gestohlen werden, was genau gefährlich ist.

Da möchte ich im übrigen mal auf Content Security Policy hinweisen.
 
Zuletzt bearbeitet:
Da kommst du um Sessions nicht herum, über mögliche Gefahren solltest du dir bewusst sein. Dass nur eine Session-ID als Cookie existiert ist vielleicht das sicherste, als irgendwie das Passwort verschlüsselt zu übertragen.

Session-Dateien kann man verschlüsseln. Das beste wäre sicher, du implementierst das selbst oder benutzt erwähntes Suhosin.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Neueste Beiträge

Zurück
Oben