nicht angemeldet
Halihallo
Deswegen die Aufteilung in SessionID und SessionKey...
Der SessionKey wird ja nur einmal generiert und mit der entsprechenden SessionID in der Datenbank verknüpft. Und da der Key nur einmal generiert wird, kann man auch gut die IP des Clients mitkodieren; aber dann muss der SessionKey jedesmal mit der SessionID mitgeschleppt werden, da er nicht mehr mit 100% Wahrscheinlichkeit rekonstruiert weden kann.
der Sinn dieser Trennung erschliesst sich mir trotzdem nicht ganz. Wenn Du die IP mal aussen vor lässt kannst Du eine eindeutige ID generieren, die eben eine "Verbindungskennung" darstellt. Wozu die Trennung? *grübel*
Hast recht, ich hätte etwas stärker (oder überhaupt?) darauf eingehen sollen:
Also eigentlich ist es ja völlig einerlei. Theoretisch...
Aber ich bin der Meinung, dass eine Trennung der beiden schon Sinn macht (oder machen kann). Z. B. werden nummerische SessionID's sicher schneller verarbeitet, als alphanummerische. Der alphanummerische Anteil lagere ich immer in den SessionKey aus; der nummerische bleibt bei der SessionID, welche dem autoincrement-Wert der Datenbank entspricht. Somit ist auch sichergestellt, dass das SessionID.SessionKey - Paar 100% unique ist (das ist allein die SessionID, da ja mit jeder neuen Session die ID um eins erhöht wird). Bei einer kryptographischen codierung "könnte", auch wenn die Wahrscheinlichkeit genen 0 strebt, eine SessionID mal nicht unique sein und schon hat man ein Problem...
Aber das ist alles ziemlich nebensächlich. Die Performanceeinbussen (kleine Zahlen werden schneller verarbeitet) und Sicherheitsrisiken (autoincrement Spalten geben eineindeutigere Werte, als der Zufallsgenerator) sind ja nun wirklich *verdammt* (man möge es mir verzeihn) klein.
Hoffe, dass mein Text etwas Sinn ergibt (auch wenn die Diskussion ziemlich spitzfindig (ich meine, ich habe kein relevantes Gegenargument für eine Ein-Wert-Session) ist).
Viele Grüsse
Philipp