The Yesod Framework

Einleitung

Entwickler von Webanwendungen versprechen sich von einem Webrahmenwerk die Möglichkeit einer einfachen, aber gleichzeitig sicheren Unterstützung der Sessionverwaltung. Gleichwohl die Speicherung von sitzungsbezogenen Informationen im Sinne einer REST-Applikation nach Möglichkeit vermieden werden sollte, ist dies in der Praxis nicht immer zu bewerkstelligen.[1] Konsequenterweise stellt somit auch Yesod die entsprechende Funktionalität bereit, um die Implementierung von Sessions zu ermöglichen. ClientSession, eines der ersten Yesod-Pakete, führt dabei zwei Konzepte ein. Zum einen werden die in der Session zu speichernden Informationen verschlüsselt, um diese für den Nutzer nicht sichtbar zu machen. Zum anderen erfolgt die Anwendung einer Signatur zur Prevention von Hijacking-Angriffen. In jedem Fall erfolgt bei jeder Anfrage zwar das erneute Senden der Sitzungsdaten, weil diese sich bei Yesod in einem Cookie befinden. Dies hat jedoch auch den Vorteil, das beispielsweise in der Regel keine Interaktion mit Datenbanken erfolgen muss und stets sichergestellt werden kann, dass alle Informationen bereit stehen.[2]

Sitzungseinstellungen

Im Rahmen einer Webapplikation ist es dem Entwickler möglich, Einstellungen bzgl. bestimmter Eigenschaften der Sessions zu tätigen. Dies geschieht allgemein über drei Funktionen, welche dem Entwickler seitens des Frameworks zu diesem Zweck zur Verfügung gestellt werden. Die Funktion encryptKey liefert beispielsweise den Schlüssel, welche von Yesod zur Verschlüsselung der Sitzungsdaten verwendet wird. Möchte man Sessions für die gesamte Webanwendung deaktivieren, so ist diese Funktion dergestalt zu überschreiben, dass sie nur noch den Maybe-Wert Nothing zurückgibt.

Die Funktion clientSessionDuration legt die Gültigkeitsdauer von Sitzungen fest. Der übergebene Wert, welcher in Minuten angegeben wird, wirkt sich technisch zweierlei aus. Zum einen erhält der Cookie, welcher für die Übertragung der Sitzungsinformationen genutzt wird, eben diese Lebensdauer. Zum anderen wird darüberhinaus überprüft, ob die Sitzung bereits abgelaufen ist, indem der aktuelle Zeitstempel mit dem Zeitstempel des definierten Gültigkeitablaufs der Sitzung verglichen wird. Bei jeder Antwort von Yesod an den Client wird innerhalb des Cookies der gewünschte Zeitpunkt des Ablaufs der Session entsprechend aktualisiert, so dass die Sitzung nicht abläuft, während der Anwender sich noch immer auf der Website befindet.

Zuletzt steht noch eine Funktion sessionIpAddress bereit, welche mögliche Hijacking-Attacken verhindern soll. Dazu wird die IP-Adresse des Nutzers in das zu speichernde Sitzungsdatenpaket eingeschlossen. Dieser Mechanismus hat jedoch den Nachteil, dass die Sitzung zurückgesetzt werden muss, sobald sich die IP-Adresse des Benutzers verändert.[3]

Praktische Anwendung von Sessions

Wie allgemein üblich, werden auch bei Yesod Werte innerhalb von Sitzungsdaten anhand eines Schlüssels identifiziert. Über diesen Schlüssel erfolgen sämtliche Zugriffe auf die Sitzungsdaten. Diese gilt es entweder mit setSession zu setzen, mit lookupSession auszulesen oder mit deleteSession zu löschen.

Zusätzliche Erweiterungen, welche auf Sessions in Yesod basieren, sind Messages und Ultimate Destinations.[4][5] Messages sind dabei nichts anderes als Werte, die in den Sitzungsdaten gespeichert und bereits nach dem ersten Abruf wieder gelöscht werden. Auf diese Weise ist es dem Entwickler besonders einfach möglich, im Rahmen einer Aktionsdurchführung in Reaktion auf eine POST-Anfrage Nachrichtentexte zu definieren, welche dem Benutzer angezeigt werden sollen, sobald die Durchführung der Aktion und eine anschließende Weiterleitung auf eine GET-Anfrage erfolgt ist.

Eine Ultimate Destination, zu deutsch «letztgültiges Ziel», stellt eine Webseite dar, auf welche der Nutzer weitergeleitet werden soll, nachdem eine POST-Anfrage gesendet wurde. Die Funktion redirectUltDest ermöglicht eben diese Weiterleitung. In der Praxis ist dies beispielsweise dann bequem, wenn Benutzer nach dem Login auf die Webseite zurückgeführt werden sollen, auf der sie sich vor dem eigenlichen Login befunden haben. Die Ultimate Destination kann auf drei unterschiedliche Arten gesetzt werden.

• setUltDest :: Route master -> GHandler sub master () - definiert die übergebene typsichere URL als Ultimate Destination,
• setUltDest' :: GHandler sub master () - definiert die aktuell verarbeitete Route als Ultimate Destination,
• setUltDestString :: String -> GHandler sub master () - definiert die übergebene URL in Form einer Zeichenkette als Ultimate Destination