Sollten Sitzungsvariablen vermieden werden?

Früher habe ich mich stark auf Sitzungsvariablen verlassen, aber in letzter Zeit haben sich viele davon als unnötig erwiesen, indem ich stattdessen Dinge wie Abfragezeichenfolgenparameter verwendete.

Ein Kollege von mir lehnt es ab, Sitzungsvariablen zu verwenden. Ist dies ein realistisches Ziel und sollten Sitzungsvariablen aus praktischen Gründen vermieden werden? Können Sitzungsvariablen vollständig vermieden werden (mit Ausnahme von Sitzungscookies, um Anmeldungen zu ermöglichen) und würde dies zu besseren Designs führen?

Einige der Gründe, warum mein Kollege sie nicht verwendet:

• Untypisierte Art von Sitzungsvariablen
• Sitzungs-Timeouts führen zu Statusverlust
• Globale Gültigkeit von Sitzungsvariablen
• Lastausgleichsserver verlieren Sitzungen (.Net-spezifisch?)
• Anwendungspools / Server werden neu gestartet
• Sie sind unnötig

Wenn Ihre Anwendung eine Sitzungsvariable enthält, fragen Sie sich Folgendes:

Welchen Wert soll meine Variable haben, wenn ich auf die Zurück-Schaltfläche meines Browsers klicke?

Wenn die Antwort "der aktuelle Wert" ist, können Sitzungsvariablen nützlich sein. Ein Beispiel wäre ein Einkaufswagen: Sie erwarten nicht, dass Dinge aus dem Einkaufswagen entfernt werden, wenn Sie die Historie durchgehen. Es ist immer in seinem aktuellen Zustand.

Wenn die Antwort "ein vorheriger Wert" ist, sollten Sie keine Sitzungsvariablen verwenden. Ich habe gesehen, dass schlechte Verwendungen das Übergeben eines Parameters zwischen Seiten beinhalten. Wenn ich auf die Schaltfläche "Zurück" klicke, um zu einer Seite zurückzukehren, erhält die Seite nicht unbedingt den richtigen Parameter. Wenn ich zwei Registerkarten öffne, wie wird sich meine Website dann verhalten?

Das richtige Verhalten der Zurück-Schaltfläche ist keineswegs das A und O, aber es hilft Ihnen, sich eine Website als zustandslose Anwendung vorzustellen. Im Allgemeinen halte ich die Verwendung von Sitzungsvariablen für selten und weit verbreitet.

Das HTTP-Protokoll ist zustandslos. Sitzungen sind eine Möglichkeit, den Clientstatus über HTTP-Anforderungen hinweg beizubehalten. Sie können dies entweder mit der integrierten Sitzungsbehandlung einer Plattform oder selbst mit Abfragezeichenfolgenparametern tun. In beiden Fällen ist für viele Aufgaben ein Sitzungskonzept erforderlich.

Ihr Kollege mag wahrscheinlich keine bestimmte Implementierung oder hat Sitzungen nicht für die beabsichtigten Zwecke verwendet. Wenn Sie Informationen zu einer bestimmten Clientverbindung über HTTP-Anforderungen hinweg beibehalten möchten, benötigen Sie eine Form der Sitzungspersistenz.

Die folgenden Probleme sind implementierungsspezifisch:

Untypisierte Art von Sitzungsvariablen

Globale Gültigkeit von Sitzungsvariablen

Server mit Lastenausgleich verlieren Sitzungen

Anwendungspools / Server werden neu gestartet

Beispielsweise arbeite ich am häufigsten in PHP und speichere meine Sitzungsinformationen in einer relationalen Datenbank. Also werden meine Sitzungsvariablen eingegeben. Lastausgleich und Serverneustarts verursachen keine Sitzungsprobleme.

Dieser ist interessanter:

Sitzungs-Timeouts führen zu Statusverlust

Sitzungen werden am häufigsten über Cookies gespeichert. Diese können vom Kunden jederzeit gelöscht werden. Sie können jedoch auch über einen Abfragezeichenfolge-Parameter beibehalten werden, sodass auf dem Client keine Zeitüberschreitung auftritt. Das Server-Timeout liegt bei Ihnen. Auch dieses Problem ist implementierungsspezifisch.

Lassen Sie uns nicht das gesamte Konzept von Sitzungen streichen, nur weil uns eine bestimmte Implementierung nicht gefällt. Jedes gute Webanwendungsframework erleichtert die ordnungsgemäße Verwendung von Sitzungen, um Benutzeranmeldungen oder andere für den aktuellen Besuch des Benutzers spezifische Elemente beizubehalten. Der Datenbankeintrag eines Benutzers kann (und sollte) verwendet werden, um bestimmte Dinge zu speichern, wenn er angemeldet ist. Anonyme Besucher verfügen jedoch möglicherweise auch über temporäre Informationen, die es wert sind, in ihrer Sitzung aufbewahrt zu werden, z. B. eine kurze Liste der zuletzt besuchten Seiten oder die Präferenz für verstecke eine Nachricht, die sie bereits gesehen haben. Im Allgemeinen sind nur kleinere temporäre Informationen für die Sitzungsspeicherung geeignet.

Andere haben viele gute Argumente angeführt (die ich nicht wiederholen werde), aber es gibt einen Aspekt der Technik Ihres Kumpels, der noch nicht besprochen wurde: Sicherheit .

Es ist unmöglich zu wissen, welche Art von Sicherheitslücken Sie öffnen, ohne sich den Code anzusehen, aber hier sind ein paar Dinge, die mir auf den Kopf gestellt werden können.

• Sitzungsfixierung : Ein leistungsfähiger Angriff, der etwas einfacher ist, wenn Sie den Benutzer nur auf einen Link klicken lassen, der bereits die erforderlichen Informationen in der URL enthält (anstatt zu versuchen, den Benutzer zu veranlassen, einen Computer zu verwenden, auf dem die Cookies entsprechend eingestellt sind).
• SQL-Injektion (oder andere böswillige Eingabe) : Vertrauen Sie niemals etwas, das vom Benutzer kommt. Sitzungsvariablen haben den Vorteil, dass sie den Server niemals verlassen, sodass der Benutzer sie nicht direkt ändern kann. Während Sie Daten bereinigen sollten, bevor Sie sie in die Sitzung einfügen, können Sie immer den Werten vertrauen, die Sie später herausgeben. Wenn alles über die Abfragezeichenfolge weitergegeben wird, müssen Sie VIELE Überprüfungen durchführen, um sicherzustellen, dass Sie keine böswilligen Eingaben akzeptieren.
• Beschädigen von Daten durch Verwendung gefälschter Eingaben : Wie viele Daten übertragen Sie ähnlich wie bei der SQL-Injection hin und her? Wie wichtig ist das? Kann ich das Verhalten Ihrer App ändern, indem ich einen Wert in der Abfragezeichenfolge ändere? Kann ich die Daten auf Ihrem Server beschädigen, indem ich Werte ändere? Wenn es mir gelingt, die Daten auf dem Server zu beschädigen, sind andere Benutzer davon betroffen? (Wenn Sie mit "Nein" geantwortet haben, lautet meine Antwort "Sind Sie sicher? Sie müssen viele Stellen überprüfen.")

All dies kann immer noch passieren, wenn Sie Sessions verwenden, aber es kann viel einfacher werden, wenn Ihr Kumpel nicht weiß, was er tut.

Sitzungsvariablen ähneln in gewissem Maße den alten globalen Basisvariablen. Es liegt in der Verantwortung des Benutzers, den Überblick zu behalten, was sich in ihnen befindet, in welchem ​​Umfang sie sich befinden und wie sie verwendet werden. Genau wie in alten Versionen von BASIC. Abgesehen davon, warum sollte jemand die Verwendung eines Mechanismus, der offensichtlich ein integraler und sehr wichtiger Bestandteil des Programmiermodells ist (ASP, MVC usw.), völlig außer Acht lassen?

Das einzig schlimme an der Verwendung von Session-Variablen ist, dass Sie die Last haben, sie zu verfolgen, sicherzustellen, dass sie mit relaventen Daten gefüllt sind und sie entsorgen.

Tun wir das nicht, wenn wir auf irgendeine Weise programmieren?

Ich dachte früher wie Ihr Kollege, weil ich einige schlechte Erfahrungen mit Debugging-Problemen in Bezug auf Sitzungsvariablen gemacht hatte, die wirklich nur Inkompetenz meinerseits waren. Ja, Sie können ohne Sitzungsvariablen auskommen, indem Sie Abfragezeichenfolgen, ausgeblendete Felder in Formularen und andere Dinge verwenden. Es wird jedoch sehr schnell mühsam, dies auf diese Weise zu tun, wenn Ihre Anwendung nicht nur über den grundlegendsten logischen Ablauf verfügt, um den Status zu bestimmen. Es besteht auch das Sicherheitsrisiko, die Funktionsweise Ihrer Anwendung über Abfragezeichenfolgen und ausgeblendete Felder anzuzeigen, von denen jedes als Angriffsvektor dienen kann.

Wenn Sie mit Sitzungsvariablen arbeiten, müssen Sie nur nachverfolgen, wann sie festgelegt und deaktiviert werden, da dies den logischen Ablauf der Anwendung bestimmt. Es ist wie Memory Management in einer Sprache wie C.

Beachten Sie, dass dies nur aus meiner Erfahrung mit PHP in einem relativ kleinen Projekt ohne Frameworks resultiert. Auf anderen Plattformen kann es anders sein, aber ich denke, dass das allgemeine Prinzip immer noch gilt.

Wie bereits erwähnt, ist HTTP Stateless und Session Variable break that. Das zustandslose HTTP-Design hilft beim Zwischenspeichern von Ressourcen. Für Ressourcen, die öffentlich verfügbar sind.

Es ist möglich, eine Website ohne Sitzungsvariable zu entwerfen, aber es ist schwieriger. Das Schwierigste (IMHO) ist das ausgefallene An- und Abmelden. HTTP-Authentifizierungsschemata bieten nicht die Tools, die zur Authentifizierung über ein HTML-Formular erforderlich sind (möglicherweise hacken Sie etwas mit Javascript - XHR an https: // untel: [email protected] ) und Es ist noch schwieriger, sich abzumelden und browserübergreifend zu arbeiten. Es gab einige Diskussionen in den W3-Mailinglisten darüber, aber wenn ich mich richtig erinnere, wurde die Idee fallen gelassen.

Im Übrigen sollten Sie in der Lage sein, ohne Sitzungsvariablen zu leben. Sie haben einen Status in einer Datenbank, in Dateien oder an einem anderen Ort, aber die Verwendung für Sitzungsvariablen sollte selten sein.

Wenn Ihr Benutzer einen Warenkorb hat, ist dies nur dann eine variable Sitzung, wenn der Benutzer auf zwei Computern / Browsern browsen kann, ohne den Warenkorb zu teilen.