Schrift
[thread]2871[/thread]

Ohne Cockies (Seite 2)



<< |< 1 2 3 4 >| >> 34 Einträge, 4 Seiten
pq
 2003-08-16 19:01
#28927 #28927
User since
2003-08-04
12208 Artikel
Admin1
[Homepage]
user image
dann machst du ein login per htaccess, aber nur für die
anwendung, mit der man daten hinzufügt, für alle anderen
kein htaccess.
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wiki:Wie frage ich & perlintro Wiki:brian's Leitfaden für jedes Perl-Problem
Strat
 2003-08-16 19:05
#28928 #28928
User since
2003-08-04
5246 Artikel
ModeratorIn
[Homepage] [default_avatar]
[quote=jan10001,16.08.2003, 16:54]
Quote
strat
man kann ja einen Gast-Zugriff bieten, der ueber
http://gast:gast@servername/path/to/file.cgi laeuft...

Ne Pflichtanmeldung möchte/muß ich vermeiden.
Ich muß das Ganze für den Besucher wirklich einfach und Idiotensicher machen. Alle Besucher landen auf einer Startseite von der Sie per Formular die Datenbank abfragen können.[/quote]
Damit hast du ja eine Anmeldung, die der User allerdings nicht mitbekommt. Du musst nur einen benutzer guest mit passwort guest erstellen... dann funktioniert ein Link auf http://user:passwort@url..., z.B.

<a href="http://gast:gast@....../">Gastzutritt</a>
perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/
jan10001
 2003-08-16 19:14
#28929 #28929
User since
2003-08-14
962 Artikel
BenutzerIn
[default_avatar]
Das ist auch nicht das Wahre, sinnvoll wäre es mit ner Session ID zu arbeiten. Da ja auch ein Gast, wenn er in der Datenbank fündig wird, Daten eingeben kann. Praktisch kann jeder Daten eingeben, aber nicht jeder will sich dauerhaft registrieren, das wäre nur für Vielnutzer sinnvoll.
jan10001
 2003-08-16 19:20
#28930 #28930
User since
2003-08-14
962 Artikel
BenutzerIn
[default_avatar]
Quote
Damit hast du ja eine Anmeldung, die der User allerdings nicht mitbekommt. Du musst nur einen benutzer guest mit passwort guest erstellen... dann funktioniert ein Link auf http://user:passwort@url..., z.B.

<a href="http://gast:gast@....../">Gastzutritt</a>

Verstehe, aber wie läuft das dann wenn sich jemand anmeldet?
Zudem liegen Login Name und Passwort eines jeden Benutzers in der Datenbank.
SirLant
 2003-08-16 19:33
#28931 #28931
User since
2003-08-04
516 Artikel
BenutzerIn
[default_avatar]
Erstelle ne Session-ID, speichere die ID+User in ner Datei/DB und häng die Session-ID an die url an.Als Session-ID kannste ja die microtime durch md5 jagen oder so.
--Programming today is a race between Software Enginers striving to build bigger and better idiot-proof Programs,
and the Universe trying to produce bigger and better idiots.
So far, the Universe is winning!
jan10001
 2003-08-16 23:48
#28932 #28932
User since
2003-08-14
962 Artikel
BenutzerIn
[default_avatar]
Quote
Erstelle ne Session-ID, speichere die ID+User in ner Datei/DB und häng die Session-ID an die url an.Als Session-ID kannste ja die microtime durch md5 jagen oder so.

Denke mal das ist es, gibt es dazu vielleicht irgendwo ne deutsch Anleitung wie man sowas umsetzen muß und an was man denken sollte?
pktm
 2003-08-17 00:18
#28933 #28933
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
Hi!
Hab diesbezgl. einen Tread von perlunity.de auf Lager:
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
Sessions für Shopsysteme 
Quelle: Threat auf perlunity.de
Hi!
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?

Zurück zur Frage, wo steht nochmal drin, ob der User AOL oder sonstwas benutzt?

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?

--> Kurze Anmerkung, wie ich mir das vorstelle (in schmuckem pseudo-perl):

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
}

mfg pktm

Hallo!
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;-)

Gruß
Kristian

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:

http://perl.black-cube.net/bin/ultraboard/UltraBoard.cgi?action=Read&BID=13&TID=20114&P=1&SID=99#ID24
aber der Link geht nicht mehr;-(

Mit den anderen Proxys hab ich eigentlich doch kein Problem, bleibt doch immer der selbe - oder?

Dann gibts da ja noch die Möglichkeit mit mod_rewrite, den hab ich aber bei meinem Provider nicht.

Hm, also - Vorschläge? :-)
mfg pktm

Hallo!
Vergiß die AOL-User und überdenke dein Session-Konzept. In einem Shop würde ich es so machen:

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 )

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.

In der Session-ID "bricht" man, bei Bedarf, den Browsercache, indem man time() mit einbaut.

Auf keinen Fall, macht man für jede Session einen Datenbankeintrag. Diese Einträge braucht man erst, wenn der Warenkorb befüllt wird.

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.

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.

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.)

So, da hast du ein paar Anregungen, die auf drei Jahren (Shopbetrieb)Erfahrung beruhen, ich hoffe sie helfen dir.

Gruß
Kristian

Hi!
Das Konzept leuchtet ein&acute;: * 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.
1. Teil: localtime + 6h, irgendwie verdreht
2. Teil: ? Warenkorb ?
Einfach eine zufallsgenerierte ID nehmen? Geht der Teil denn nicht verkoren, wenn ich stillschweigend eine neue ID vergebe?

mfg pktm

Hallo
> Das Konzept leuchtet ein&acute;:
> * Cookie immer setzen, wenn möglich
> * SID in request mitgeben
Hmm, nein, da habe ich gefaselt, einen Cookie gibt es nur, wenn er was in den Warenkorb legt.

Beispiel Sid:

perl -e '$sid = time() . "XY" . rand(1) . "ZZ" . time() . "XY" . rand(1) . "ZZ" . time();
$sid =~ s/\./PT/g;
print"$sid\n"'

Ausgabe:
1050269667XY0PT917397911734046ZZ1050269667XY0PT0304125736906542ZZ1050269677

Wenn du das jetzt immer an ZZ zerlegst hast du drei Teile. Warenkorb, eigentliche Sid und Cachebrecher. Jeder Teil hat sein eigenes Startdatum.

Beim nächsten Aufruf wäre die Sid z.B.

1050269667XY0PT917397911734046ZZ1050269667XY0PT0304125736906542ZZ1050269700

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:

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.

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.

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.

Sind damit alle Klarheiten restlos beseitigt?;-)

Gruß Kristian

PS: 6 Stunden / 7 Wochen kann man natürlich durch andere Werte ersetzen

Hi,
denke mal, dass bei AOL für die IP auch ein hostname mit "AOL" existiert. So wie bei t-online oder netcologne:

>>dial-213-168-xx-xxx.netcologne.de<<

so kommst du an den hostnamen ran:

#!/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";

gruß klaus

Ende
http://www.intergastro-service.de (mein erstes CMS :) )
pktm
 2003-08-17 00:22
#28934 #28934
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
Da dachte ich mir, poste ich auch noch gleich den Code:
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
...
use constant SESSION_TIME => '60000'; #ms
...
# ---- CGI
my $cgi = CGI->new();
my $query = $cgi->Vars();
# ---- SETTINGS
my %subs = ();
$subs{relative_url} = $cgi->url(-relative=>1);
$subs{full_url} = $cgi->url(-full=>1);
...
print $cgi->header(-charset=>'ISO-8859-1',
                  -expires=>'+1s',
                  -type=>'text/html',
                  );

if( (exists $query->{sid})                                                      # wenn session existiert
and validate_session( $query->{sid} ) ){                                          # und gültig ist
       #session verlängern
       $query->{sid} = time() . "XY" . (split /XY/, $query->{sid})[1];
       #settings
       $subs{self} = $subs{relative_url} . '?sid=' . $query->{sid} . '&file=' . $query->{file};
       $subs{query} = '?sid=' . $query->{sid} . '&file=' . $query->{file};
       $subs{domain} = "http://" . DOMAIN;
       $subs{sid} = $query->{sid};
       $subs{file} = $query->{file};
...
}else{ #wenn keine session existiert / session nicht gültig ist
       if( exists $query->{action}
       and $query->{action} eq "login"
       and main::validate_login($query->{usn}, $query->{pwd}) ){
           $query->{sid} = time() . "XY" . rand(1);
           $query->{sid} =~ s/\./PT/g;
           #settings
           $subs{self} = $subs{relative_url} . '?sid=' . $query->{sid} . '&file=' . $query->{file};
           $subs{query} = '?sid=' . $query->{sid} . '&file=' . $query->{file};
           $subs{domain} = "http://" . DOMAIN;
           # erstes einloggen => INDEX
           print qq~<h1>Login korrekt!</h1>~;
           print qq~<p><a href="$subs{self}">weiter &gt;&gt;&gt;</a></p>~;
           print qq~<p>SID: $query->{sid}</p>~;
           print qq~<p>file: $query->{file}</p>~;
       }else{
           print $loginForm;
       }
}
exit( 1 );
...
# --------------------------------------------------------
# SUBS
# --------------------------------------------------------
sub validate_login{
# ---- usage
# if( validate_login( $query->{usn}, $query->{pwd} ) ){ print "Login ok!\n"; }
# ---- requirements
# modul: Crypt::PasswdMD5
# $passfile -> File mit USN|PWD(cryptedBy: Crypt::PasswdMD5)\n
   my ($usn, $pwd) = @_;
   my $return = 0;
   open(DAT, $passfile) || die "$! ($passfile)";
   flock DAT, 1 if UNIX;
   my @passfile = <DAT>;
   close(DAT);
   foreach ( @passfile ){
       chomp $_;
       if( $usn eq (split /\|/,$_)[0] ){
           if (unix_md5_crypt($pwd, (split /\|/,$_)[1])
              eq (split /\|/,$_)[1] ) {
               # Passwort in Ordnung
               $return = 1;
           }else{
               $return = 0;
           }
       }else{
           $return = 0;
       }
   }
   return $return;
}
# --------------------------------------------------------
sub validate_session{
# ---- usage
# if( validate_session( $sessionDataToValidate ) ){ print "Session Ok!\n"; }
# ----
# 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;
}
# --------------------------------------------------------

Müsste so in etwa stimmen.
mfg pktm\n\n

<!--EDIT|pktm|1061065495-->
http://www.intergastro-service.de (mein erstes CMS :) )
jan10001
 2003-08-17 00:52
#28935 #28935
User since
2003-08-14
962 Artikel
BenutzerIn
[default_avatar]
Danke, das war genau was ich brauchte!
Jetzt ist mir klar wie es ablaufen sollte und wo die Schwächen liegen.
Viele Grüße,
Jan
pktm
 2003-08-17 18:41
#28936 #28936
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
Das wär doch mal was gutes für die FAQ oder?
http://www.intergastro-service.de (mein erstes CMS :) )
<< |< 1 2 3 4 >| >> 34 Einträge, 4 Seiten



View all threads created 2003-08-16 12:38.