Zugriff auf Sessions
lima-city → Forum → Programmiersprachen → C/C++ und D
ansatz
anwendung
benutzer
datei
datenbank
datum
ende
festlegen
halten
hinweis
idee
nutzer
problem
projekt
session
speichern
system
verbindung
vergessen
webseite
-
Hallo,
ich schreibe grade an einer Anwendung, welche via Websockets mit einer Webseite kommuniziert. Nun stehe ich vor dem Problem, dass der Benutzer sich auf der Webseite zur Nutzung des Dienstes authentifiziert - und diese Authentifizierung an die in C++ geschriebene Anwendung weiter geben soll. Da ich nun aus diversen Gründen nicht unbedingt per Javascript mit Benutzernamen und Passwörtern um mich werfen will, hatte ich geplant, einfach die Session-ID via Websocket an das Programm weiter zu geben.
Das Problem beginnt da, wo ich nun die Session-ID mit einem Benutzernamen in Verbindung bringen muss. Ich muss also irgendwie die Session-Daten vom Webserver (Apache/Nginx/Lighttpd/etc.) auslesen. Nun stoße ich aber auf das Problem, dass jeder Webserver seine eigenen Vorlieben zu haben scheint, wie und wo er diese speichert. Da ich mich ungern auf einen Webserver festlegen und die Anwendung portabel halten möchte, interessiert mich nun, ob es da irgendwelche Standards oder sogar Bibliotheken gibt, an die man sich halten kann.
Alternativ könnte ich mir vorstellen, ein eigenes, Datenbank-Basiertes Session-System zu basteln. Da für das Web-Frontend sowieso ein Datenbank-Server vorhanden sein muss, läge dies eigentlich nahe.
Wie würdet ihr dieses Problem lösen? Fallen euch andere Lösungsansätze ein? Kennt ihr gute Bibliotheken um in C++ Session-Daten von Webservern auszulesen? Oder gibt es da Standards, an die man sich ggf. halten kann? -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Wenn ich das richtig verstanden habe, würde ich das in etwa so lösen:
Beim Login des Benutzers wird seine aktuelle SessionID in die DB mit den Login Daten geschrieben. Da müsste es eine halbwegs brauchbare Funktion bei PHP geben [session_id()]. Man könnte an der Stelle auch mit anderen Codes, Ketten, Zahlen etc arbeiten, Hauptsache die ist einem und nur einem Account zur selben Zeit zugeordnet. Das dann an den an den Websocket weiter reichen und dort dann erneut die DB Abfragen um den Nutzer zu ermitteln.
Alternativ dazu habe ich noch etwas gefunden, was eventuell auch funktioniert, vielleicht ist da was dabei.
https://www.webtoolkit.eu/wt
http://cppcms.com/wikipp/en/page/tut_sessions -
Erstmal vielen Dank für die Antwort.
Wenn ich das richtig verstanden habe, würde ich das in etwa so lösen:
Beim Login des Benutzers wird seine aktuelle SessionID in die DB mit den Login Daten geschrieben.
Die Überlegung hatte ich auch schon, diesen speziellen ansatz aber wieder verworfen - da man in solch einem Fall auch gleich ein komplettes Datenbank-Basiertes Session-System basteln könnte. Letztenendes fällt mir kaum ein Fall ein, in dem in der Session wesentlich mehr als eine Verknüpfung der Session-ID mit einem Benutzer stehen müsste. (Und natürlich ein Ablaufzeitpunkt...)
Ich sehe also keinen wirklichen Vorteil darin, die Session-ID mehrfach zu speichern. Oder übersehe ich da was?
Alternativ dazu habe ich noch etwas gefunden, was eventuell auch funktioniert, vielleicht ist da was dabei.
https://www.webtoolkit.eu/wt
http://cppcms.com/wikipp/en/page/tut_sessions
Das erste sieht interessant aus - auch wenn ich auf den ersten Blick noch keinen wirklichen Nutzen für meinen Fall sehe. Werde ich mir mal genauer ansehen.
Das Zweite durchschaue ich noch nicht wirklich, scheint aber im wesentlichen ebenfalls schwerlich mit meinem bisherigen Konzept vereinbar. Zudem scheint das ganze den Fokus eher auf Optimierung gegenüber PHP ausgelegt zu sein. Aber möglicherweise findet man dort einen Ansatz, der hilfreich wäre.
Ich werde mich auf jeden Fall mit beidem mal eingehend befassen und ggf. mein Konzept überarbeiten.
Vielen Dank für deine Hinweise. -
Wenn du die Session-ID zum Benutzer in der Datenbank speicherst, musst du jedenfalls daran denken, dass ein Nutzer mehrere aktive Sessions (und daher auch mehrere gültige Session-IDs) gleichzeitig haben kann. Also eher Nutzer zur Session speichern. Und dann nicht vergessen, dass Sessions ablaufen und/oder zerstört werden, also musst du auch wieder aufräumen.
Eine Standardlösung für dein Problem ist übrigens die Nutzung von Tokens: wenn die Webseite aufgerufen wird, wird ein Token erstellt und dazu gespeichert, um welchen Benutzer es sich handelt (oder der Token wird C++-Anwendung direkt gegeben und dort im Speicher [z.b. in einer Hashtabelle] gehalten, wie auch immer). Dieser Token kommt in die Webseite und wird vom JavaScript zur Authentifizierung genutzt. Die C++-Anwendung bekommt den Token somit per Websocket und kann herausfinden, welchem Benutzer er gehört. Wurde der Token einmalig benutzt ist er ungültig, wurde er innerhalb von x Minuten (z.B. 5min) nicht benutzt läuft er ebenfalls ab (→ Token wieder löschen). Damit bist du völlig unabhängig von PHP-Sessions o.ä. (ich gehe mal davon aus, dass du PHP-Sessions o.ä. meinst, denn der Webserver selbst hat normalerweise keine Session).
Ansonsten gibt es auch Möglichkeiten um die Session-Daten direkt von PHP (o.ä.) in einer Datenbank speichern zu lassen. Ob man das für deinen Zweck nutzen will oder nicht ist halt die Frage.
Beitrag zuletzt geändert: 23.10.2018 21:38:28 von hackyourlife -
hackyourlife schrieb:
Wenn du die Session-ID zum Benutzer in der Datenbank speicherst, musst du jedenfalls daran denken, dass ein Nutzer mehrere aktive Sessions (und daher auch mehrere gültige Session-IDs) gleichzeitig haben kann. Also eher Nutzer zur Session speichern. Und dann nicht vergessen, dass Sessions ablaufen und/oder zerstört werden, also musst du auch wieder aufräumen.
Ja, ich schätze das sollte an sich nicht das große Problem darstellen. Die Benutzer-ID muss ja nicht eindeutig sein. Das mit dem Aufräumen ja ein einfaches
auf alles wo der aktuelle aktuelle Zeitpunkt > Ablaufzeitpunkt. (Im Zweifelsfall per cronjob)DELETE
hackyourlife schrieb:
Eine Standardlösung für dein Problem ist übrigens die Nutzung von Tokens: wenn die Webseite aufgerufen wird, wird ein Token erstellt und dazu gespeichert, um welchen Benutzer es sich handelt (oder der Token wird C++-Anwendung direkt gegeben und dort im Speicher [z.b. in einer Hashtabelle] gehalten, wie auch immer). Dieser Token kommt in die Webseite und wird vom JavaScript zur Authentifizierung genutzt. Die C++-Anwendung bekommt den Token somit per Websocket und kann herausfinden, welchem Benutzer er gehört. Wurde der Token einmalig benutzt ist er ungültig, wurde er innerhalb von x Minuten (z.B. 5min) nicht benutzt läuft er ebenfalls ab (? Token wieder löschen).
Okay, aber das klingt mir auch wieder nach einer Anwendung von (sehr kurzlebigen) Session-Äquivalenten. Nicht, dass ich die Idee verwerfen würde - wie ja schon eingangs geschrieben, ist das eine Lösung, die ich auch schon ins Auge gefasst habe. Oder ist da ein wesentlicher Unterschied zwischen "Token" und "Session", den ich aktuell nicht durchschaue?
Könntest du näher ausführen, wie du "oder der Token wird [der] C++-Anwendung direkt gegeben und dort im Speicher [...] gehalten" meinst? Ich hatte schon über Lösungen via IPC nachgedacht - die bestmögliche Variante um sowas umzusetzen die ich bisher gefunden habe war Unix-Sockets zu verwenden und das ganze von PHP quasi auf einem Nebenkanal zu übergeben. Erschien mir bisher jedoch als unnötig kompliziert - da in dem Projekt so oder so Datenbanken verwendet werden.
hackyourlife schrieb:
Damit bist du völlig unabhängig von PHP-Sessions o.ä. (ich gehe mal davon aus, dass du PHP-Sessions o.ä. meinst, denn der Webserver selbst hat normalerweise keine Session).
Natürlich, ich meinte PHP-Sessions - wobei ich tatsächlich bisher fälschlicherweise den Webserver als verantwortlichen im Kopf hatte. (Obwohl es jetzt, wo du es erwähnst natürlich klar ist.) Zumindest scheint es zumindest inkonsistenzen beim Speicherort/Format zwischen unterschiedlichen Webservern/Betriebssystemen/PHP-Versionen zu geben. Zumindest scheinen die Sessions zwischen Lighhtpd/Apache bzw. Arch/Debian unterschiedlich gespeichert zu sein.
hackyourlife schrieb:
Ansonsten gibt es auch Möglichkeiten um die Session-Daten direkt von PHP (o.ä.) in einer Datenbank speichern zu lassen. Ob man das für deinen Zweck nutzen will oder nicht ist halt die Frage.
Das einzige was ich dazu gefunden habe, wäre via
, etc. die entsprechenden Funktionen zu überschreiben. Habe ich da irgendwas (einfacheres?) übersehen?session_set_save_handler() -
noxious schrieb:
Der wichtigste Unterschied ist, dass eine »Session« für längere Zeit bzw. über mehrere Anfragen hinweg besteht, während der vorgeschlagene (Einmal-)Token nach einmaliger Benutzung »verbraucht« wird / seine Gültigkeit verliert.
Okay, aber das klingt mir auch wieder nach einer Anwendung von (sehr kurzlebigen) Session-Äquivalenten. Nicht, dass ich die Idee verwerfen würde - wie ja schon eingangs geschrieben, ist das eine Lösung, die ich auch schon ins Auge gefasst habe. Oder ist da ein wesentlicher Unterschied zwischen "Token" und "Session", den ich aktuell nicht durchschaue?
Könntest du näher ausführen, wie du "oder der Token wird [der] C++-Anwendung direkt gegeben und dort im Speicher [...] gehalten" meinst? Ich hatte schon über Lösungen via IPC nachgedacht - die bestmögliche Variante um sowas umzusetzen die ich bisher gefunden habe war Unix-Sockets zu verwenden und das ganze von PHP quasi auf einem Nebenkanal zu übergeben. Erschien mir bisher jedoch als unnötig kompliziert - da in dem Projekt so oder so Datenbanken verwendet werden.
Wenn du sowieso eine Datenbank nutzt, dann ist dieser Ansatz nicht sinnvoll. Gemeint war, dass der PHP-Code eine Verbindung zur C++-Anwendung aufmachen könnte (z.B. per UNIX-Socket) und ihr Token + User übermitteln könnte, sodass die C++-Anwendung völlig ohne Datenbank diese Zuordnung temporär in einer Datenstruktur im Speicher halten kann. Da aber offenbar sowieso eine Datenbank zum Einsatz kommt ist das wohl kaum sinnvoll.
Das einzige was ich dazu gefunden habe, wäre via
Das ist eine Möglichkeit, eine andere wäre z.B. die Option
, etc. die entsprechenden Funktionen zu überschreiben. Habe ich da irgendwas (einfacheres?) übersehen?session_set_save_handler()
in der php.ini und da z.B. einen memcached zu konfigurieren. Oder eben Dateien nutzen und einen passenden Pfad festlegen, auf den auch deine C++-Anwendung Zugriff hat.session.save_handler
Falls du tatsächlich die PHP-Session direkt in der C++-Anwendung nutzen willst (z.B. via memcached, gemeinsamen Session-Ordner o.ä.) muss dir klar sein, dass du dann den Inhalt der Session lesen können musst. Wenn ich mich recht erinnere ist das eine PHP-serialisierte Version von
.$_SESSION -
hackyourlife schrieb:
Ein interessanter Aspekt, über den ich bisher noch nicht nachgedacht habe. Wobei ich mir erst nicht sicher war, ob ich das überhaupt möchte, bin ich nun überzeugt, dass dies durchaus hilfreiche Nebeneffekte haben kann. Vielen dank für den Hinweis.
Der wichtigste Unterschied ist, dass eine »Session« für längere Zeit bzw. über mehrere Anfragen hinweg besteht, während der vorgeschlagene (Einmal-)Token nach einmaliger Benutzung »verbraucht« wird / seine Gültigkeit verliert.
hackyourlife schrieb:
Richtig, eine ähnliche Idee hatte ich auch schon. Wie schon gesagt aus genau diesem Grund hab ich das beiseite gelegt. Aber vielleicht bringt das ja einen späteren Leser ein mal voran.
Wenn du sowieso eine Datenbank nutzt, dann ist dieser Ansatz nicht sinnvoll. Gemeint war, dass der PHP-Code eine Verbindung zur C++-Anwendung aufmachen könnte (z.B. per UNIX-Socket) und ihr Token + User übermitteln könnte, sodass die C++-Anwendung völlig ohne Datenbank diese Zuordnung temporär in einer Datenstruktur im Speicher halten kann. Da aber offenbar sowieso eine Datenbank zum Einsatz kommt ist das wohl kaum sinnvoll.
hackyourlife schrieb:
Änderungen an der php.ini oder ähnliches würde ich jedoch gerne aus Gründen er portabilität vermeiden. Deshalb würde ich gerne so wenig wie möglich "invasive" Einstellungen vornehmen. Es wäre schön, wenn man das Projekt am Ende ohne größere Probleme einfach von System-A zu System-B portieren könnte, ohne sich besonders viele Gedanken darüber machen zu müssen, wie nun der (möglicherweise schon laufende) Webserver konfiguriert ist.
Das ist eine Möglichkeit, eine andere wäre z.B. die Option
in der php.ini und da z.B. einen memcached zu konfigurieren. Oder eben Dateien nutzen und einen passenden Pfad festlegen, auf den auch deine C++-Anwendung Zugriff hat.session.save_handler
Falls du tatsächlich die PHP-Session direkt in der C++-Anwendung nutzen willst (z.B. via memcached, gemeinsamen Session-Ordner o.ä.) muss dir klar sein, dass du dann den Inhalt der Session lesen können musst. Wenn ich mich recht erinnere ist das eine PHP-serialisierte Version von
.$_SESSION
Das Festlegen eines Pfades für die Dateien ist auch eine Möglichkeit, die ich bisher noch nicht in Betracht gezogen habe - danke für. Obwohl die Funktion
ja eigentlich ziemlich offensichtlich ist. Damit wäre dann zumindest der Speicherort der Sessions nachvollziehbar und etwaige system-spezifische Einstellungen wären überschrieben. Auch, wenn ich in diesem speziellen Fall bisher zu der Token-Lösung tendiere, könnte das doch in Zukunft irgendwann mal hilfreich sein.session_save_path
Ein weiteres Thema auf welches du mich gebracht hast ist die ganze "memcached"-Geschichte. Auch, wenn mein Projekt bisher eher klein ausgelegt ist, sollte man sich doch so viel Platz nach oben frei halten wie möglich. Aber da das Thema für mich relativ neu ist, werde ich mich da wohl mal genauer rein lesen müssen.
Also vielen Dank für die Hinweise. -
Nicht vergessen: Seit PHP 5.3 (oder so um den Dreh rum) kannst du auch einige Änderungen über eine ".user.ini" und eine ".htaccess" vornehmen. Je nachdem wie PHP auf deinem Webserver eingerichtet ist.
Du kannst ja beides anlegen. Dann bleibt deine Anwendung auch portabel. -
muellerlukas schrieb:
Nun, das einzige was möglicherweise dagegen spräche wäre, dass eine Version von PHP vorzuschreiben ist ja im wesentlichen wieder eine Restriktion was die Portabilität angeht. Natürlich ist es fraglich, ob eine PHP-Version früher als 5.3 überhaupt noch relevant vertreten ist - aber wenn man das ganze am Ende in irgendein Uralt-Projekt integrieren will und bei PHP schnell mal Dinge obsolet werden, wären die Leute am Ende gezwungen ihr vorhandenes Projekt komplett umzustellen. (Was in dem Fall möglicherweise eine ganz gute Idee wäre...)
Nicht vergessen: Seit PHP 5.3 (oder so um den Dreh rum) kannst du auch einige Änderungen über eine ".user.ini" und eine ".htaccess" vornehmen. Je nachdem wie PHP auf deinem Webserver eingerichtet ist.
Du kannst ja beides anlegen. Dann bleibt deine Anwendung auch portabel.
Aber danke für den Tipp. Das mit .htaccess war mir bewusst, aber die .user.ini ist mir neu. Eine möglicherweise interessante Möglichkeit, nicht-invasive Änderungen an der Konfiguration für einzelne Projekte zu realisieren.
Dennoch favorisiere ich bisher die Token-Lösung. Unter anderem weil ich denke, dass es einfacher wäre, eine PHP-Session über einen Websocket zu "Bruteforcen" als über einzelne Seitenaufrufe, zum anderen weil ich denke es ist sicherer, so wenig wie möglich mit PHP-Sessions um sich zu werfen.
Aber vielen Dank für den Hinweis. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
