<html>
<head>
<title>Sessions für Shopsystem</title>
<style type="text/css">
td{ border: 1pt outset #EEEEEE; background-color: white}
th{ background-color: ghostwhite; }
h1.sub-title { font-size: 16pt; }
</style>
</head>
<body bgcolor="#EEEEEE">
<h1>Sessions im Request für Shopsysteme</h1>
<h1 class="sub-title">Sessions ohne Speicherung der Session-Daten (Cookies, Files, DB)</h1>
<li>Das System
<li>Vorteile - Nachteile
<li>Codebeispiel für nicht-cookiebasierte Sessions
<li>Original-Perlunity-Thread (kopiert, damit Quelle nicht verloren geht)
<hr />
<h2>Das System</h2>
<li>Cookies
<p>Man geht davon aus, dass keine Cookies beim User möglich sind. ( Wenn das Gegenteil bewiesen ist, übergibt man die SID doch besser in einem Cookie und nicht im Request )</p>
<li>Verfallsdatum
<p>Die Session-ID braucht dringend ein Verfallsdatum. (z.B. 6 Stunden) (Bspl.: Die Kunden eines Shopsystems verlinken einzelne Produktseiten, samt ihrer ID...) Wenn eine ID verfallen ist vergibt man stillschweigend eine neue. Wenn eine falsche ID eingegeben wurde ( mit ner Regex das Schema prüfen ) vergibt man stillschweigend eine neue.</p>
<li>Kontra Abspeichern der Session
<p>Auf keinen Fall, macht man für jede Session einen Datenbankeintrag. Diese Einträge braucht man erst, wenn der Warenkorb befüllt wird.</p>
<li>Der Warenkorb
<p>Warenkörbe haben einen extra Platz in so einer ID. Dieser Teil ist, wenn der Warenkorb befüllt wurde, immer gleich. Eigentlich ist das eine zweite ID innnerhalb der Session. Dieser Teil hat ein längeres Haltbarkeitsdatum (12 Wochen), wird aber, bei einer abgelaufenen Sid, nur akzeptiert, wenn er aus einen Cookie kommt.</p>
<li>Suchmaschinen und Spider
<p>Auf Suchmaschinen (Spider) muß man achten. Wenn die sich in so einen Shop verbeissen und Dank der ewig neuen Sid's, ewig neue Seiten finden kann das unschön enden. (Ich würde hier KFSW::SpiderDetect empfehlen, wenn ich es schon veröffentlicht hätte. SCNR) Ein erkannter Spider bekommt eine fixe ID, z.B. my_shop_name, dann findet er jede mögliche Seite nur einmal und gut ist. Da die Id nicht dem normalen Schema entspricht wird sie bei einem normalen User-Request ersetzt. (s.o) Dabei gibt es entweder eine neue ID oder, wenn der User schon einen Cookie haben sollte, die ID aus dem Cookie.</p>
<li>Sicherheit
<p>Alles Sicherheitsdenken, Kontrollierwünsche etc scheitern an der zu hohen Systemlast. Plane die Sids ohne irgendwelche sicherheitsrelevanten Features. (Für den Adminbereich mußt du natürlich was anderes machen.)</p>
<li>Beispiel Sid:
<pre>
perl -e '$sid = time() . "XY" . rand(1) . "ZZ" . time() . "XY" . rand(1) . "ZZ" . time();
$sid =~ s/\./PT/g;
print"$sid\n"'
Ausgabe:
1050269667XY0PT917397911734046ZZ1050269667XY0PT0304125736906542ZZ1050269677
</pre>
<p>Wenn du das jetzt immer an ZZ zerlegst hast du drei Teile. Warenkorb, eigentliche Sid und Cachebrecher. Jeder Teil hat sein eigenes Startdatum.</p>
<p>Beim nächsten Aufruf wäre die Sid z.B.<p>
<pre>
1050269667XY0PT917397911734046ZZ1050269667XY0PT0304125736906542ZZ1050269700
</pre>
<p>Dieser String wird jetzt wie folgt geprüft: Erstmal eine RegEx drüber ob das Ding passen kann. Wenn das OK ist, geht es weiter:</p>
<p>Codebeispiel:</p>
<pre>
sub validate_session{
# ---- usage
# if( validate_session( $sessionDataToValidate ) ){ print "Session Ok!\n"; }
# requires: constant SESSION_TIME = 123; #ms
# ----
# prüfen, ob gültige sid: a)muster b)haltbarkeit
my $session = $_[0];
my $return = 0;
if( $session =~ /\d{10}XY\d*PT\d{10}/
and (split /XY/, $session)[0] > time() - SESSION_TIME ){
$return = 1;
}
return $return;
}
# --------------------------------------------------------
</pre>
<p>a.) Wenn die Sid aus einem Cookie kommt, bleibt der erste Teil für z.B. sieben Wochen gültig.
Der zweite Teil wird nach z.B. 6 Stunden erneuert.
Der dritte Teil wird bei jedem Request durch time() ersetzt.</p>
<p>b.) Wenn die Sid nicht aus einem Cookie kommt, gibt es nach 6 Stunden eine komplett neue Sid.
Der dritte Teil wird bei jedem Request durch time() ersetzt.</p>
<li>Warum dieses System?
Damit funktionieren Warenkörbe zwar nur mit Cookie richtig gut, aber ein Kunde, der in den Shop kommt und keine Cookies hat, kann dort in Ruhe einkaufen. (Er muß natürlich in 6 Stunden durch sein) Anders geht es leider nicht, denn wenn man die Warenkorbinformation aus dem Query-String länger als X Stunden akzeptiert, hat man wieder das Problem mit den Kunden, die Shopseiten verlinken und Ihre Sid im Link lassen. Gleiches gilt für versehentlich nicht erkannte WebSpider.
<hr />
<h2>Vorteile - Nachteile</h2>
<h3>Vorteile</h3>
<li>Es werden keine unnötigen Daten gespeichert
<li>Funktioniert auch ohne Cookies (die jeder Benutzer deaktivieren kann)
<li>
<h3>Nachteile</h3>
<li>Wenn der Benutzer keine Cookies annimmt kann er nur für einen begrenzten Zeitraum einkaufen
<li>Spider raffen die Session nicht und finden so immer neue Seiten)
<li>st nicht sicher genug - die Session ist immer einen bestimmten Zeitraum gültig. Kommt jemand anderes an die Session ran kann er sie ausnutzen
<hr />
<h2>Codebeispiel für nicht-cookiebasierte Sessions</h2>
<pre>
<!--c1--><table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td><b>Code</b> </td></tr><tr><td id="CODE"><!--ec1--><br>...<br>use constant SESSION_TIME =&> &'60000&'; #ms<br>...<br># ---- CGI<br>my &$cgi = CGI-&>new&(&);<br>my &$query = &$cgi-&>Vars&(&);<br># ---- SETTINGS<br>my %subs = &(&);<br>&$subs{relative_url} = &$cgi-&>url&(-relative=&>1&);<br>&$subs{full_url} = &$cgi-&>url&(-full=&>1&);<br>...<br>print &$cgi-&>header&(-charset=&>&'ISO-8859-1&',<br> -expires=&>&'+1s&',<br> -type=&>&'text/html&',<br> &);<br><br>if&( &(exists &$query-&>{sid}&) # wenn session existiert<br>and validate_session&( &$query-&>{sid} &) &){ # und gültig ist<br> #session verlängern<br> &$query-&>{sid} = time&(&) . &"XY&" . &(split /XY/, &$query-&>{sid}&)&[1&];<br> #settings<br> &$subs{self} = &$subs{relative_url} . &'?sid=&' . &$query-&>{sid} . &'&file=&' . &$query-&>{file};<br> &$subs{query} = &'?sid=&' . &$query-&>{sid} . &'&file=&' . &$query-&>{file};<br> &$subs{domain} = &"http&://&" . DOMAIN;<br> &$subs{sid} = &$query-&>{sid};<br> &$subs{file} = &$query-&>{file};<br>...<br>}else{ #wenn keine session existiert / session nicht gültig ist<br> if&( exists &$query-&>{action}<br> and &$query-&>{action} eq &"login&"<br> and main&:&:validate_login&(&$query-&>{usn}, &$query-&>{pwd}&) &){<br> &$query-&>{sid} = time&(&) . &"XY&" . rand&(1&);<br> &$query-&>{sid} =~ s/&\./PT/g;<br> #settings<br> &$subs{self} = &$subs{relative_url} . &'?sid=&' . &$query-&>{sid} . &'&file=&' . &$query-&>{file};<br> &$subs{query} = &'?sid=&' . &$query-&>{sid} . &'&file=&' . &$query-&>{file};<br> &$subs{domain} = &"http&://&" . DOMAIN;<br> # erstes einloggen =&> INDEX<br> print qq~&<h1&>Login korrekt&!&</h1&>~;<br> print qq~&<p&>&<a href=&"&$subs{self}&"&>weiter &gt;&gt;&gt;&</a&>&</p&>~;<br> print qq~&<p&>SID&: &$query-&>{sid}&</p&>~;<br> print qq~&<p&>file&: &$query-&>{file}&</p&>~;<br> }else{<br> print &$loginForm;<br> }<br>}<br>exit&( 1 &);<br>...<br># --------------------------------------------------------<br># SUBS<br># --------------------------------------------------------<br>sub validate_login{<br># ---- usage<br># if&( validate_login&( &$query-&>{usn}, &$query-&>{pwd} &) &){ print &"Login ok&!&\n&"; }<br># ---- requirements<br># modul&: Crypt&:&:PasswdMD5<br># &$passfile -&> File mit USN&|PWD&(cryptedBy&: Crypt&:&:PasswdMD5&)&\n<br> my &(&$usn, &$pwd&) = @_;<br> my &$return = 0;<br> open&(DAT, &$passfile&) &|&| die &"&$&! &(&$passfile&)&";<br> flock DAT, 1 if UNIX;<br> my @passfile = &<DAT&>;<br> close&(DAT&);<br> foreach &( @passfile &){<br> chomp &$_;<br> if&( &$usn eq &(split /&\&|/,&$_&)&[0&] &){<br> if &(unix_md5_crypt&(&$pwd, &(split /&\&|/,&$_&)&[1&]&)<br> eq &(split /&\&|/,&$_&)&[1&] &) {<br> # Passwort in Ordnung<br> &$return = 1;<br> }else{<br> &$return = 0;<br> }<br> }else{<br> &$return = 0;<br> }<br> }<br> return &$return;<br>}<br># --------------------------------------------------------<br>sub validate_session{<br># ---- usage<br># if&( validate_session&( &$sessionDataToValidate &) &){ print &"Session Ok&!&\n&"; }<br># ----<br># prüfen, ob gültige sid&: a&)muster b&)haltbarkeit<br> my &$session = &$_&[0&];<br> my &$return = 0;<br> if&( &$session =~ /&\d{10}XY&\d*PT&\d{10}/<br> and &(split /XY/, &$session&)&[0&] &> time&(&) - SESSION_TIME &){<br> &$return = 1;<br> }<br> return &$return;<br>}<br># --------------------------------------------------------<br><!--c2--></td></tr></table><!--ec2-->
</pre>
<hr />
<h2>Original-Perlunity-Thread (kopiert, damit Quelle nicht verloren geht)</h2>
<table>
<tr>
<th>Sessions für Shopsysteme</th>
</tr>
<td>Quelle: Threat auf <a href="http://www.perlunity.de">perlunity.de</a></td>
</tr>
<tr>
<td>
<p>
Hi!<br />
Will mir gerade ein Session-Management-Teil stricken.
Dazu wollte ich den User über die IP identifizieren
(mehr dazu siehe weiter unten).
Bei AOL-Usern ist das aber etwas doof, weil die ja jedesmal eine
andere IP haben (weis nicht mehr genau wieso, war glaube ich wegen anonymen
Proxy oder so - egal).
Trifft das noch auf andere User-Gruppen zu?
</p>
<p class="b"> Zurück zur Frage, wo steht nochmal drin, ob der User AOL oder sonstwas benutzt?</p>
<p>
Dann noch was zum Session-Teil.
Hatte eigentlich vor, auf Kekse soweit es geht zu verzichten.
Jetzt steht allerdings Leistungsfähigkeit & Sicherheit gegen Kekse.
Wieso sollte man nochmal auf den Einsatz von Keksen verzichten?
(außer, dass manche Leute Kekse aus verständlichen Gründen deaktivieren)
Was würdet ihr machen?</p>
<p>--> Kurze Anmerkung, wie ich mir das vorstelle (in schmuckem pseudo-perl):</p>
<pre>
if( AOL-User ){
Keks mit SessionID setzen
Eintrag in Session-DB, mit SessionID & "AOL"
}else{
Eintrag in Session-DB mit SessionID & IP
#optional: Keks setzen
}
</pre>
<p>mfg pktm</p>
</td></tr><tr><td>
<p>
Hallo!<br />
Die IP ist generell keine gute Idee. Nebst AOL benutzen viele Provider Proxis,
ob für den Kunden sichtbar oder nicht. Wenn du uns sagst, wofür du die Session
brauchst und warum du keines der vorhandenen Module nutzen willst,
ist es einfacher dir etwas zu raten.
Ich mache je nach Bedarf mal Sessions mit Cookies oder im Querystring,
mit TimeOut oder ohne, bei Cookies aber geneerell mit Fallback, für den Fall,
daß der User keine Kekse will. Es kommt auf den Anwendungsbereich an.
Ganz am Anfang habe ich mal, im Shop, für jeden Sch.... ne Session angelegt mit
Kontrollfunktion etc.
Ab 1000 Dateien pro Tag wird man da ruhiger;-)</p>
<p>Gruß<br />
Kristian</p>
</td></tr><tr><td>
<p>
Das mit den 1000 Dateien kann ich glaube ich verstehen.
Die Session wollte ich in mein Shopsystem einbauen.
Einmal für den Admin-Bereich und einmal für den Warenkorb.
Das mit AOL ist irgendwie was spezielles, weil die Leute jedesmal über eine
anderen Proxy geschickt werden,
mehr dazu gabs mal hier:</p>
<a href="http://perl.black-cube.net/bin/ultraboard/UltraBoard.cgi?action=Read&BID=13&TID=20114&P=1&SID=99#ID24" target="_blank">
http://perl.black-cube.net/bin/ultraboard/UltraBoard.cgi?action=Read&BID=13&TID=20114&P=1&SID=99#ID24</a>
<p>aber der Link geht nicht mehr;-(</p>
<p>Mit den anderen Proxys hab ich eigentlich doch kein Problem, bleibt doch immer
der selbe - oder?</p>
<p>Dann gibts da ja noch die Möglichkeit mit mod_rewrite, den hab ich aber bei
meinem Provider nicht.</p>
<p>Hm, also - Vorschläge? :-)<br />
mfg pktm</p>
</td></tr><tr><td>
<p>
Hallo!<br />
Vergiß die AOL-User und überdenke dein Session-Konzept.
In einem Shop würde ich es so machen:</p>
<p>Erstmal geht man davon aus, daß keine Cookies beim User möglich sind.
( Wenn das Gegenteil bewiesen ist, übergibt man die SID in einem Cookie und
nicht im Request )</p>
<p>Die Session-ID braucht dringend ein Verfallsdatum. (z.B. 6 Stunden)
(Die Kunden verlinken einzelne Produktseiten, samt ihrer ID...)
Wenn eine ID verfallen ist vergibt man stillschweigend eine neue.
Wenn eine falsche ID eingegeben wurde ( mit ner Regex das Schema prüfen )
vergibt man stillschweigend eine neue.</p>
<p>In der Session-ID "bricht" man, bei Bedarf, den Browsercache, indem man time()
mit einbaut.</p>
<p>Auf keinen Fall, macht man für jede Session einen Datenbankeintrag. Diese
Einträge braucht man erst,
wenn der Warenkorb befüllt wird.</p>
<p>Warenkörbe haben einen extra Platz in so einer ID. Dieser Teil ist, wenn der
Warenkorb befüllt wurde, immer gleich. Eigentlich ist das eine zweite ID
innnerhalb der Session. Dieser Teil hat ein längeres Haltbarkeitsdatum
(12 Wochen), wird aber, bei einer abgelaufenen Sid, nur akzeptiert, wenn er aus
einen Cookie kommt.</p>
<p>Auf Suchmaschinen (Spider) muß man achten. Wenn die sich in so einen Shop
verbeissen und Dank der ewig neuen Sid's, ewig neue Seiten finden kann das
unschön enden. (Ich würde hier KFSW::SpiderDetect empfehlen, wenn ich es schon
veröffentlicht hätte. SCNR)
Ein erkannter Spider bekommt eine fixe ID, z.B. my_shop_name, dann findet er
jede mögliche Seite nur einmal und gut ist. Da die Id nicht dem normalen Schema
entspricht wird sie bei einem normalen User-Request ersetzt. (s.o)
Dabei gibt es entweder eine neue ID oder, wenn der User schon einen Cookie
haben sollte, die ID aus dem Cookie.</p>
<p>Alles Sicherheitsdenken, Kontrollierwünsche etc scheitern an der zu hohen
Systemlast. Plane die Sids ohne irgendwelche sicherheitsrelevanten Features.
(Für den Adminbereich mußt du natürlich was anderes machen.)</p>
<p>So, da hast du ein paar Anregungen, die auf drei Jahren (Shopbetrieb)Erfahrung
beruhen, ich hoffe sie helfen dir.</p>
<p>Gruß<br />
Kristian</p>
</td></tr><tr><td>
<p>
Hi!<br />
Das Konzept leuchtet ein´:
* Cookie immer setzen, wenn möglich
* SID in request mitgeben
Nur das mit dem Warenkorb hab ich nicht so ganz verstanden.
Die SID besteht aus 2 Teilen.<br />
1. Teil: localtime + 6h, irgendwie verdreht<br />
2. Teil: ? Warenkorb ?<br />
Einfach eine zufallsgenerierte ID nehmen?
Geht der Teil denn nicht verkoren, wenn ich stillschweigend eine neue ID
vergebe?</p>
<p>mfg pktm</p>
</td></tr><tr><td>
<p>
Hallo<br />
> Das Konzept leuchtet ein´:<br />
> * Cookie immer setzen, wenn möglich<br />
> * SID in request mitgeben<br />
Hmm, nein, da habe ich gefaselt, einen Cookie gibt es nur, wenn er was in den
Warenkorb legt.</p>
<p>Beispiel Sid:</p>
<pre>
perl -e '$sid = time() . "XY" . rand(1) . "ZZ" . time() . "XY" . rand(1) . "ZZ" . time();
$sid =~ s/\./PT/g;
print"$sid\n"'
Ausgabe:
1050269667XY0PT917397911734046ZZ1050269667XY0PT0304125736906542ZZ1050269677
</pre>
<p>Wenn du das jetzt immer an ZZ zerlegst hast du drei Teile.
Warenkorb, eigentliche Sid und Cachebrecher.
Jeder Teil hat sein eigenes Startdatum.</p>
<p>Beim nächsten Aufruf wäre die Sid z.B.</p>
<pre>
1050269667XY0PT917397911734046ZZ1050269667XY0PT0304125736906542ZZ1050269700
</pre>
<p>Dieser String wird jetzt wie folgt geprüft:
Erstmal ne regex drüber ob das Ding passen kann.
Wenn das OK ist, geht es weiter:</p>
<p>a.) Wenn die Sid aus einem Cookie kommt, bleibt der erste Teil für z.B. sieben
Wochen gültig.<br />
Der zweite Teil wird nach z.B. 6 Stunden erneuert.<br />
Der dritte Teil wird bei jedem Request durch time() ersetzt.</p>
<p>b.) Wenn die Sid nicht aus einem Cookie kommt, gibt es nach 6 Stunden eine
komplett neue Sid.<br />
Der dritte Teil wird bei jedem Request durch time() ersetzt.</p>
<p>Damit funktionieren Warenkörbe zwar nur mit Cookie richtig gut, aber ein Kunde,
der in den Shop kommt und keine Cookies hat, kann dort in Ruhe einkaufen.
(Er muß natürlich in 6 Stunden durch sein)
Anders geht es leider nicht, denn wenn man die Warenkorbinformation aus dem
Query-String länger als X Stunden akzeptiert, hat man wieder das Problem mit
den Kunden, die Shopseiten verlinken und Ihre Sid im Link lassen.
Gleiches gilt für versehentlich nicht erkannte WebSpider.</p>
<p>Sind damit alle Klarheiten restlos beseitigt?;-)</p>
<p>Gruß Kristian</p>
<p>PS: 6 Stunden / 7 Wochen kann man natürlich durch andere Werte ersetzen</p>
</td></tr><tr><td>
<p>
Hi,<br />
denke mal, dass bei AOL für die IP auch ein hostname mit "AOL" existiert.
So wie bei t-online oder netcologne:</p>
<pre>
>>dial-213-168-xx-xxx.netcologne.de<<
</pre>
<p>so kommst du an den hostnamen ran:</p>
<pre>
#!/usr/bin/perl -w
use strict;
use CGI::Carp qw(fatalsToBrowser);
print "Content-type: text/html\n\n";
print '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">', "\n";
print "<html><head><title>Host-Ausgabe der REMOTE-Adresse</title></head><body><pre>\n";
use Socket;
my $remote=$ENV{'REMOTE_ADDR'};
my $addr = inet_aton($remote);
my $Wert = gethostbyaddr($addr, AF_INET);
print "$Wert\n";
print "</pre></body></html>\n";
</pre>
<p>gruß klaus</p>
</td></tr><tr><td>
<p>Ende</p>
</td></tr>
</table>
<hr />
</body>
</html>
Jemand zu Hause?![[twitter]](/battie/theme/default/icons/twitter.gif){kind=icon}
![[Homepage]](/battie/theme/default/homepage.gif)
Wie frage ich & perlintro 
Schrift
Blog
Einstellungen![[feed]](/battie/theme/default/icons/feed.png){kind=icon}
![[Powered by Battie]](/battie/img/powered.png)
