nicht angemeldet
gibts sowas wie eine sessionsID? ->eindeutige identifikation
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
gibts sowas wie eine sessionsID? ->eindeutige identifikation
hallo,
in php gibts ja bekanntlich die $_SESSION ID.
Nun stellt sich mir die frage ob es was ähnliches für perl gibt?
Habe bei der suche nach session nichts für perl gefunden.
Im moment benutze ich anstatt session die methode length($ENV{'HTTP_USER_AGENT'}) und dessen IP-adresse als identifikation .Ist für eine shopping cart datenbank,jeder user hat eine eigene shoppingcart-name-datenbank.In meinem beispiel könnte die shopping carte so 67-213.7.44.1 also lenghtUseragent-IP heissen.
Mit cookies möcht ich das übrigens nicht machen.
Gruss vom
Alain
-
Halihallo Alain
in php gibts ja bekanntlich die $_SESSION ID.
Nun stellt sich mir die frage ob es was ähnliches für perl gibt?Es gibt Session-Module. Diese Module erstellen wohl auch irgendwelche
ID's um die Sessions zu unterscheiden.Habe bei der suche nach session nichts für perl gefunden.
Nicht in Perl direkt vielleicht, aber Session-Module gibt es wirklich
einige!Im moment benutze ich anstatt session die methode length($ENV{'HTTP_USER_AGENT'}) und dessen IP-adresse als identifikation.
Bitte, bitte nicht! - Über USER_AGENT und IP ist die Eindeutigkeit
bzw. die Identität eines Computers wirklich überhaupt nicht zu
identifizieren! - Entweder musst du es über Cookies oder über
Mitschleppen der SessionID (falls darin nicht kodiert, auch der
SessionKey [Sicherheitsaspekt!]) umsetzen!Ist für eine shopping cart datenbank,jeder user hat eine eigene shoppingcart-name-datenbank.In meinem beispiel könnte die shopping carte so 67-213.7.44.1 also lenghtUseragent-IP heissen.
Wie wo was? - Du legst für jeden User eine eigene Datenbank an?
Mit cookies möcht ich das übrigens nicht machen.
Dann *musst* du die SessionID/SessionKey über die URL mitschleppen.
Aber USER_AGENT/IP ist in etwa genauso zuverlässig, wie die
SessionID bei jedem Request über einen Zufallszahlengenerator zu
erraten!Viele Grüsse
Philipp
-
(H)allo Alain,
Im moment benutze ich anstatt session die methode length($ENV{'HTTP_USER_AGENT'}) und dessen IP-adresse als identifikation .Ist für eine shopping cart datenbank, ...
In deinem Laden würde ich gerne mal online einkaufen ...
(Natürlich mit gefälschter Browserkennung und Call-by-Call-IP-Adresse)Mit cookies möcht ich das übrigens nicht machen.
Was spräche gegen Cookies?
-
hi,
Im moment benutze ich anstatt session die methode length($ENV{'HTTP_USER_AGENT'}) und dessen IP-adresse als identifikation .Ist für eine shopping cart datenbank, ...
In deinem Laden würde ich gerne mal online einkaufen ...
(Natürlich mit gefälschter Browserkennung und Call-by-Call-IP-Adresse)gefälschter browser erkennung?Was bringt Dir das?Es geht ja nicht darum,wer Du bist und mit was du surfst,sondern darum dass die shoppingcard bzw. perl dich erkennt,wenn du mehrere sachen einkaufst z.b. und im einklang mit anderen benutzern die event. gleichzeitig auf diesen shop zugreifen,damit perl diese user unterscheiden kann von einander und nicht darum das Du mich verars... möchtest mit deinem gespooften browser-useragent.Solange du den useragent nicht änderst bei dieser shoppingcard wird auch deine karte erkannt und sonst wird eine neue karte für dich erstellt.
naja,eigentlich wäre der name jeder shopping card store1-IP,was dann
noch weniger eindeutig wäre.Was spräche gegen Cookies?
Weil nicht jeder Browser den cookie aktiviert hat und weil es zu kompliziert ist.
Grüsse
Alain-
Was spräche gegen Cookies?
Weil nicht jeder Browser den cookie aktiviert hat und weil es zu kompliziert ist.
Naja, Cookies sind einfacher als Session IDs. Du musst sie bei jeder Übertragung mitschleppen, d.h. alle deine Links und Formulare müssen die ID enthalten. Ich weiß nicht wie das in PHP gelöst ist, aber in Perl musst du das von Hand machen.
Struppi. -
hi Alain,
... gefälschter browser erkennung? Was bringt Dir das? Es geht ja nicht darum, wer Du bist und mit was du surfst,sondern darum dass die shoppingcard bzw. perl dich erkennt,wenn du mehrere sachen einkaufst z.b. und im einklang mit anderen benutzern die event. gleichzeitig auf diesen shop zugreifen,damit perl diese user unterscheiden kann von einander und nicht darum das Du mich verars... möchtest mit deinem gespooften browser-useragent.Solange du den useragent nicht änderst bei dieser shoppingcard wird auch deine karte erkannt und sonst wird eine neue karte für dich erstellt.
Wenn du als "eindeutiges" Erkennungsmerkmal die Browserkennung und die (Remote-)IP benutzt, und der "Einkaufende" aus irgendeinem Grund die Verbindung abbricht, sieht sich jemand anderes mit der selben IP-Adresse und der selben Browserkennung unter Umständen plötzlich einem gefüllten Warenkorb gegenüber, der aber nicht von ihm beladen worden ist. Nicht jeder hat eine feste IP-Adresse, denk nur mal an Internet-Cafés ...
Weil nicht jeder Browser den cookie aktiviert hat und weil es zu kompliziert ist.
An der ersten Hälfte deiner Aussage ist was dran. Aber Session-IDs beispielsweise per GET zu übergeben ist aber auch nicht unkomplizierter.
-
-
-
Hallo Alain,
in php gibts ja bekanntlich die $_SESSION ID.
Ich hab mir für PHP auch meine eigene Session-Klasse geschrieben. Das geht sicher auch in Perl.
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch-
Hallo Andreas,
Ich hab mir für PHP auch meine eigene Session-Klasse geschrieben. Das geht sicher auch in Perl.
klingt interessant,aber dazu hätte ich jetzt doch noch ne frage,
bleibt eine sessionID immer dieselbe vom jeweiligen benutzer?
Und wenn ja wie erzeugt man eine solche bzw. wie wird eine session zusammen gesetzt,dass die einerseits dieselbe bleibt,jedoch von anderen benutzer unterschieden wird?
Grüsse
Alain-
bleibt eine sessionID immer dieselbe vom jeweiligen benutzer?
naklar, bzw. sie bleibt die gleiche während einer Session eben, also während einer online-Sitzung.
Und wenn ja wie erzeugt man eine solche
da hat fastix® Dir ja schon eine Methode genannt. Ich habe nur eine große Zufallszahl mit md5 behandelt.
bzw. wie wird eine session zusammen gesetzt,dass die einerseits dieselbe bleibt,jedoch von anderen benutzer unterschieden wird?
in PHP ist es auch nur eine Zufallszahl. Ich weiß gar nicht, ob sie gespeichert wird, um doppelte Verwendung zu vermeiden. Das kannst Du ja machen, bzw. sie muß zur Erkennung der Session-Datei ja sowieso im Dateinamen stehen. Bei einer 32byte-ID kann man allerdings davon ausgehen, daß doppelte Verwendung zu gemeinsamer Zeit _höchst_ unwahrscheinlich ist.
_Dieselbe_ bleibt sie doch dadurch, daß der User sie bei _jeder_ Anfrage wieder mitliefert (query-String oder Cookie oder post-Daten). Wenn das einmal unterbleibt, ist die Session unterbrochen und kann nicht wieder aufgenommen werden. Beim nächsten Besuch hat der User natürlich eine andere SessionID, es sei denn, Du gibts ihm ein dauer-Cookie, aber dann ist es doch eher eine UserID.
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch
-
-
-
Moin!
Im moment benutze ich anstatt session die methode length($ENV{'HTTP_USER_AGENT'}) und dessen IP-adresse als identifikation
Keine gute Idee. Ist nicht eindeutig genug. Sämtliche Benutzer mit derselben AOL-Software und demselben AOL-Proxy sind nicht zu unterscheiden.
Wie baut man eine bessere Session- ID? Ok. Du nimmst:
a) die IP-Adresse der Anmeldung,
b) den Zeitpunkt des Session-Erstellung,
c) eine hinreichend große Zufallszahl.Das verbindest Du zu einem string. Diesen veschlüsselst Du z.B. mit MD5 oder crypt. Bei ecrypt musst Du ggf. noch urlcodieren.
Schon hast Du eine schöne Session-ID....
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Development. Auch für seriöse Agenturen.-
Moin fastix®,
Wie baut man eine bessere Session- ID? Ok. Du nimmst:
a) die IP-Adresse der Anmeldung,
b) den Zeitpunkt des Session-Erstellung,
c) eine hinreichend große Zufallszahl.na gut ich habs mal versucht mit einer zeit variable die 1 stunde gültig ist,bzw. etwas länger.Die ID kennung sieht jetzt so aus:
my $host = $ENV{'REMOTE_ADDR'};
my $jetzt = time();
my $woche = int($jetzt / 100000); #nicht ganz eine woche
my $agent = length($ENV{'HTTP_USER_AGENT'})||'667';
my $storeid = $woche + $agent;
my $storename = "$storeid"||'store1';
my $reffile = "$tmpdir/$storename-$host";das $reffile ist die datenbank für den jeweiligen benutzer der shopkarte.
Das verbindest Du zu einem string. Diesen veschlüsselst Du z.B. mit MD5 oder crypt. Bei ecrypt musst Du ggf. noch urlcodieren.
naja md5 ist wohl nicht nötig :)
mir ist das mitschleppen und einbinden einer session im url zu aufwendig,daher erzeuge ich 1woche_sessionID die dann etwas weniger als 1 woche gültig ist,sofern das da oben korrekt ist.
Grüsse
Alain-
mir ist das mitschleppen und einbinden einer session im url zu aufwendig,daher erzeuge ich 1woche_sessionID die dann etwas weniger als 1 woche gültig ist,sofern das da oben korrekt ist.
Wie willst du den an die ID kommen, wenn du kein Cokie setzt?
Wenn ich eine Sekunde später auf deine Seite komme, erhalte ich doch eine neue ID. Du musst die ID entweder mitschleppen oder einen Cookie setzen anders kannst du den Besucher nicht identifizieren.
Struppi.
-
Wenn ich eine Sekunde später auf deine Seite komme, erhalte ich doch eine neue ID. Du musst die ID entweder mitschleppen oder einen Cookie setzen anders kannst du den Besucher nicht identifizieren.
OK. Ich hab mich vertan.
du teilst die sekunden durch 100.000. Trotz allem ist deine Usererkennung anhand einer evtl. eindeutigen IP eher vom Zufall abhängig, da fast niemand solch eine IP hat.
Struppi.
-
hi Struppi,
du teilst die sekunden durch 100.000. Trotz allem ist deine Usererkennung anhand einer evtl. eindeutigen IP eher vom Zufall abhängig, da fast niemand solch eine IP hat.
wie soll ich das verstehen?
my $host = $ENV{'REMOTE_ADDR'};
hat doch jeder.Die ID setzt sich aus $host und
zeit (sekunden durch 100000)+länge vom useragent string zusammen und die bleibt ja dann bestehen 24h.
Dumm wäre nur wenn der betreffende user gerade um 23.55Uhr auf meine seite trifft und den shop um 00.01 Uhr fertigstellt,dann ist seine ID ne andere,aber das wäre ein zufall zumal ich jeden monat mit einer bestellung rechnen kann(mein shop ist nicht gerade besucherfreudig :) )
Grüsse
Alain-
wie soll ich das verstehen?
my $host = $ENV{'REMOTE_ADDR'};
hat doch jeder.ja, und eine Sekunde später evtl. eine andere. Was Du beschreibst (Wechsel nach 24 Stunden ist vielleicht bei Flatrates so, aber bei anderen Zugängen doch nicht). Warum sträubst Du Dich so gegen das übergeben der ID?
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch-
hi Andreas,
my $host = $ENV{'REMOTE_ADDR'};
hat doch jeder.ja, und eine Sekunde später evtl. eine andere. Was Du beschreibst (Wechsel nach 24 Stunden ist vielleicht bei Flatrates so, aber bei anderen Zugängen doch nicht). Warum sträubst Du Dich so gegen das übergeben der ID?
hmmm,das ist dümmer wenn die IP nach ner sekunde wechselt ;-(
Ich würde mich ja nicht sträuben gegen einer (session?)ID,wenn ich sie nicht in einer url einbinden müsste.
Ich bräuchte eigentlich nur eine zufällige zahl vom benutzer,dessen wert aber eine gewisse zeit hält und nicht jedesmal wechselt bei jedem zugriff.
Die id-karte(ID vom benutzer) wir übrigens nach dem kauf gelöscht.
Grüsse
Alain-
Ich bräuchte eigentlich nur eine zufällige zahl vom benutzer,dessen wert aber eine gewisse zeit hält und nicht jedesmal wechselt bei jedem zugriff.
ebent! der typische Fall einer SessionID. Es ist wohl auch _wahrscheinlich_, daß die IP eine Zeitlang hält, aber mehr auch nicht. Und wenn es Dir in der URL nicht passt, Cookies sind in der Tat etwas unsicher, dann mußt Du Deine Seiten halt so basteln, daß man _immer_ ein POST-Forumlar abschickt, um zur nächsten Seite zu kommen. Ginge das?
Alternativ könntest Du nur Http-Auth machen, aber da muß der User sich vor dem Einkauf einloggen.
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch-
hi,
ebent! der typische Fall einer SessionID. Es ist wohl auch _wahrscheinlich_, daß die IP eine Zeitlang hält, aber mehr auch nicht. Und wenn es Dir in der URL nicht passt, Cookies sind in der Tat etwas unsicher, dann mußt Du Deine Seiten halt so basteln, daß man _immer_ ein POST-Forumlar abschickt, um zur nächsten Seite zu kommen. Ginge das?
Alternativ könntest Du nur Http-Auth machen, aber da muß der User sich vor dem Einkauf einloggen.
hmm,ich habe jetzt noch was probiert und es scheint mir gut zu funktionieren und zwar (doch) mit crypt.
Ich habe da jetzt eine andere methode als mit time()/100000 gefunden.
Ich suche als erstes das verzeichniss nach alten dateien (alte kartenIDs)ab die älter als ein tag sind und lösche diese,dann wird eine neue karte bzw.
den IDnamen der karte erstellt und zwar wie folgt:
my $agent_now = $ENV{'HTTP_USER_AGENT'}||'777555';
$agent_now =~ s/[^1-9]|4//g; #alle Buchstaben raus plus zahlen 0 und 4
$agent_now++ unless $agent_now;
my $storeid = crypt($agent_now, "55");
$storeid =~ s/[^A-Za-z]//g;#alle sonderzeichen etc. ausser Buchstaben ersetzten
my $storename = "$storeid"||'store1';dann hab ich einen schönen namen ohne sonderzeichen wie "/" (der ja auch vorkommen könnte durch crypt) was ja dann zum error führen würde,da perl die datei nicht finden würde.Ausserdem wird ja der lange string vom useragent abgeschnitten durch crypt,was ja auch nicht schlecht ist.
Gruss
Alain-
Hallo,
[...]
ich kann kein Perl und verstehe die Ausdrücke nicht ganz. Aber wenn ich recht sehe, hast Du Dir nur eine neue Methode ausgedacht, wie Du die ID erstellst.
Die zentrale Frage von allen hier war aber: wie willst Du den User bei _jedem_ Seitenaufruf wiedererkennen? Er _muß_ sich jedesmal irgendwie ausweisen, da es keine feste Verbindung gibt.
dann hab ich einen schönen namen ohne sonderzeichen wie "/" (der ja auch vorkommen könnte durch crypt)
einfacher bekommst Du wie schon erwähnt einen Sonderzeichenfreien String mit md5.
Die Grundsatzfrage der Übergabe bleibt aber und die hättest Du mit der Energie, die Du bisher in verschiedene Verschlüsselungsverfahren gesteckt hast längst gelöst.
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch-
你好 Andreas,
dann hab ich einen schönen namen ohne sonderzeichen wie "/" (der ja auch
vorkommen könnte durch crypt)einfacher bekommst Du wie schon erwähnt einen Sonderzeichenfreien String
mit md5.Naja, md5 macht einfach nur eine Hash-Summe von 16x1 Byte. Du musst
das schon Hex-codieren, damit da was sonderzeichenfreies dabei rauskommt :)再见,
CK-
Naja, md5 macht einfach nur eine Hash-Summe von 16x1 Byte. Du musst
das schon Hex-codieren, damit da was sonderzeichenfreies dabei rauskommt :)ach, ich dachte das verwendet nur [a-zA-Z0-9]. Hat bei mir jedenfalls noch nichts anderes gemacht.
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch-
你好 Andreas,
Naja, md5 macht einfach nur eine Hash-Summe von 16x1 Byte. Du musst
das schon Hex-codieren, damit da was sonderzeichenfreies dabei
rauskommt :)ach, ich dachte das verwendet nur [a-zA-Z0-9]. Hat bei mir jedenfalls
noch nichts anderes gemacht.Wenn du die PHP-Funktion md5() meinst, die gibt (per Default) eine
Hex-codierte md5-Summe raus, ja. Aber das md5-Verfahren selber liefert, wie
erwaehnt, 16x1 Byte ohne Ruecksicht auf irgendwelche non-printables oder
sowas.再见,
CK-
Wenn du die PHP-Funktion md5() meinst, die gibt (per Default) eine
Hex-codierte md5-Summe raus, ja.hehe, ist der Default denn auf dem Self-Server so eingestellt? Ich verwende das nämlich für das file-Locking in der Z.-Sammlung.
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch-
你好 Andreas,
Wenn du die PHP-Funktion md5() meinst, die gibt (per Default) eine
Hex-codierte md5-Summe raus, ja.hehe, ist der Default denn auf dem Self-Server so eingestellt?
Guck doch in die Doku :) (Auf deutsch: ja, ist es).
Ich verwende das nämlich für das file-Locking in der Z.-Sammlung.
Du hast ein eigenes File-Locking implementiert? Warum?
再见,
CK-
Du hast ein eigenes File-Locking implementiert? Warum?
weil die Aussagen im Archiv zur flock()-Funktion derart wiedersprüchlich waren, daß ich am Ende immer noch nicht wußte, ob es denn nun wirklich funktioniert oder nicht. Und meine Tests haben da nichts Aufschlußreiches ergeben. Es war mir mit dem gleichen Script von mehreren Clients aufgerufen immmer möglich die (schon gesperrte) Datei erneut zu sperren (laut Rückgabe der Funktion). Da waren mir einfach keine Tests möglich, z.B. ob denn die Fehlermeldung korrekt ausgegeben wird und ob eine Datei auch wieder freigegeben wurde. Mit meiner eigenen Funktion kann ich es sogar unter WIN98 testen :-)
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch-
你好 Andreas,
Du hast ein eigenes File-Locking implementiert? Warum?
weil die Aussagen im Archiv zur flock()-Funktion derart wiedersprüchlich
waren, daß ich am Ende immer noch nicht wußte, ob es denn nun wirklich
funktioniert oder nicht.Es funktioniert -- auf Unix-Systemen. Auf Windows haengt es von der
PHP-Version ab.Und meine Tests haben da nichts Aufschlußreiches ergeben. Es war mir
mit dem gleichen Script von mehreren Clients aufgerufen immmer möglich
die (schon gesperrte) Datei erneut zu sperren (laut Rückgabe der
Funktion).Dir ist klar, dass die Datei nur zur Laufzeit gesperrt ist? Ist das
Script beendet, ist auch der Lock aufgehoben.Da waren mir einfach keine Tests möglich, z.B. ob denn die
Fehlermeldung korrekt ausgegeben wird und ob eine Datei auch wieder
freigegeben wurde. Mit meiner eigenen Funktion kann ich es sogar unter
WIN98 testen :-)Ich wuerde mir das ueberlegen. Mit solchen Aktionen baut man sich sehr schnell entweder Deadlocks oder race conditions. Ein richtiger[tm]
Filelocking-Mechanismus ist nicht trivial.再见,
CK-
Es funktioniert -- auf Unix-Systemen. Auf Windows haengt es von der
PHP-Version ab.laut PHP-Doku auch vom Dateisystem, wovon z.B. auch WIN98 betroffen ist.
Dir ist klar, dass die Datei nur zur Laufzeit gesperrt ist? Ist das
Script beendet, ist auch der Lock aufgehoben.ich habe deshalb in die Testdatei ein sleep() eingebaut. Ob das nun zur Laufzeit zählt, weiß ich nicht. Aber was nützt mir das Ganze, wenn ich es nicht testen kann?
Mit solchen Aktionen baut man sich sehr schnell entweder Deadlocks oder race conditions.
Ich glaube nicht. Ich gebe die Datei automatisch nach einer festgelegten Zeit (im Moment 30 Sekunden) wieder frei. Ist getestet und funktioniert.
"race conditions" ist, wenn ich richtig nachschlage, der Vorgang, daß Prozess B die Daten von Prozess A überschreibt. Auch das wird vor dem Schreiben der Datei nochmal überprüft. Kommt mir sehr unwahrscheinlich vor. Der Prozess darf nur schreiben, wenn er nach allen Datenänderungen immer noch im Besitz der aktuellen lock-ID ist.
Ich wuerde mir das ueberlegen.
Im Moment lieber nicht. Ich will das auch irgendwann mal fertig haben - fürs Erste jedenfalls. Gegen Änderungen irgendwann mal ist grundsätzlich nichts einzuwenden. Ich habe mich mehrmals nach dem Thema hier erkundigt und bin nicht zu zufriedenstellenden Ergebnissen gekommen. Lieber so als einen groben, nicht überprüfbaren Fehler mit der 'offiziellen' Methode.
Ich bitte auch zu bedenken, daß das Projekt in meinem Forum immer zur Diskussion stand und die Beteilligung der Devs etwa 0 war. Somit bin ich auf meine eigenen Ideen angewiesen und will als Entwickler auch mal entwickeln. Wenn ich immer wieder was übern Haufen schmeißen soll wird das nicht fertig.
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch-
你好 Andreas,
Es funktioniert -- auf Unix-Systemen. Auf Windows haengt es von der
PHP-Version ab.laut PHP-Doku auch vom Dateisystem, wovon z.B. auch WIN98 betroffen ist.
Ja, richtig, das hatte ich vergessen.
Dir ist klar, dass die Datei nur zur Laufzeit gesperrt ist? Ist das
Script beendet, ist auch der Lock aufgehoben.ich habe deshalb in die Testdatei ein sleep() eingebaut. Ob das nun zur
Laufzeit zählt, weiß ich nicht.Jepp, tut es.
Aber was nützt mir das Ganze, wenn ich es nicht testen kann?
Einige Sachen kann man halt nicht oder nur schwer testen :) Was meinst du,
warum manche schweren Bugs erst hier im Forum auftreten?"race conditions" ist, wenn ich richtig nachschlage, der Vorgang,
daß Prozess B die Daten von Prozess A überschreibt. Auch das wird vor
dem Schreiben der Datei nochmal überprüft. Kommt mir sehr
unwahrscheinlich vor. Der Prozess darf nur schreiben, wenn er nach
allen Datenänderungen immer noch im Besitz der aktuellen lock-ID ist.Eine “Race Condition” tritt z. B. dann auf, wenn der Lock-Vorgang nicht
atomar ist. Also z. B. dann, wenn ich mit Lock-Dateien arbeite: Prozess A
prueft, ob die Datei vorhanden ist. Sie ist noch nicht vorhanden und
deshalb geraet A in den kritischen Bereich, wird dann aber vom Scheduler
schlafen gelegt um mit Prozess B fortzufahren. Prozess B prueft dann auch,
ob eine Lock-Datei vorhanden ist und geraet auch in den kritischen Bereich.
Beide legen eine Lock-Datei an (auch eine nicht-atomare Operation). Wer
hat nun den Lock?War nur ein simples Beispiel, gibt auch viel kompliziertere Systeme, in
denen das auftreten kann.Ich wuerde mir das ueberlegen.
Im Moment lieber nicht. [...]
_Mir_ fliegt es ja nicht um die Ohren :)
[...]
Ich habe mich mehrmals nach dem Thema hier erkundigt und bin nicht zu
zufriedenstellenden Ergebnissen gekommen.Hab ich nicht gesehen, ehrlich gesagt.
Ich bitte auch zu bedenken, daß das Projekt in meinem Forum immer
zur Diskussion stand und die Beteilligung der Devs etwa 0 war.Tut mir leid, aber davon habe ich nichts mitbekommen -- ich habe zwar
ein- oder zweimal eine Mail von dir bekommen, auf eine habe ich nicht
geantwortet weil ich da gerade voll im Stress war, aber das wars dann
eigentlich auch.再见,
CK--
Es ist uns nicht möglich, in einem Bereich unseres Lebens richtig zu verhalten, wenn wir in allen anderen falsch handeln. Das Leben ist ein unteilbares Ganzes.
http://wwwtech.de/-
Dir ist klar, dass die Datei nur zur Laufzeit gesperrt ist? Ist das
Script beendet, ist auch der Lock aufgehoben.
ich habe deshalb in die Testdatei ein sleep() eingebaut. Ob das nun zur
Laufzeit zählt, weiß ich nicht.
Jepp, tut es.demnach hätte sich bei den Tests aber für den jeweils zweiten Aufruf innerhalb dieser Zeit ein "schon gesperrt" ergeben müssen...
Eine “Race Condition” tritt z. B. dann auf, wenn der Lock-Vorgang nicht
atomar ist. Also z. B. dann, wenn ich mit Lock-Dateien arbeite: Prozess A
prueft, ob die Datei vorhanden ist. Sie ist noch nicht vorhanden und
deshalb geraet A in den kritischen Bereich, wird dann aber vom Scheduler
schlafen gelegt um mit Prozess B fortzufahren. Prozess B prueft dann auch,
ob eine Lock-Datei vorhanden ist und geraet auch in den kritischen Bereich.
Beide legen eine Lock-Datei an (auch eine nicht-atomare Operation). Wer
hat nun den Lock?der letzte eben. Aber deswegen wird bei mir _vor_ dem Auslesen gelockt und vor dem Schreiben nochmal nachgesehen. Wenn ein fremd-Prozess den Lock überschreibt, kann der erste nicht mehr schreiben. Es müßte schon passieren, daß beide eine leere lockdatei finden, A schreibt den Lock, liest die Hauptdatei aus, verändert die Daten, kontrolliert die Lockdatei: o.k. Und _danach_ erst schreibt B die Lockdatei zurück und darf die Hauptdatei lesen. Wenn jetzt A die Hauptdatei zurückschreibt liest B vielleicht was Falsches aus. Kommt mir sehr unwahrscheinlich vor. Im Zweifel könnte man noch das Zeitfenster begrenzen: wer die Lockdatei nicht innerhalb einer bestimmten Zeit zurückschreiben kann bekommt den Lock nicht. Und der Andere muß mindestens diese Zeit abwarten bevor er den Lock das zweite Mal ausliest. Wird schon gehen, vertrau mir ;-)
Ich wuerde mir das ueberlegen.
Im Moment lieber nicht. [...]
_Mir_ fliegt es ja nicht um die Ohren :)wußte gar nicht, daß die SELF-Server explosiv sind ;-)
sieh Dir die Funktionen an, wenn es bei Dir ist, und wenns wirklich zu grottenschlecht sein sollte, kannst Du ja immer noch meckern.Ich bitte auch zu bedenken, daß das Projekt in meinem Forum immer
zur Diskussion stand und die Beteilligung der Devs etwa 0 war.
Tut mir leid, aber davon habe ich nichts mitbekommenwie dem auch sei. Verstehe bitte, daß ich einfach anfangen wollte und den Eindruck hatte, Diskussion ist da nicht sonderlich erwünscht. War mir auch nicht danach, euch immer wieder mit Mails zu nerven.
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch-
你好 Andreas,
Dir ist klar, dass die Datei nur zur Laufzeit gesperrt ist? Ist das
Script beendet, ist auch der Lock aufgehoben.
ich habe deshalb in die Testdatei ein sleep() eingebaut. Ob das
nun zur Laufzeit zählt, weiß ich nicht.
Jepp, tut es.demnach hätte sich bei den Tests aber für den jeweils zweiten Aufruf
innerhalb dieser Zeit ein "schon gesperrt" ergeben müssen...Abhaengig von den o.g. Faktoren :)
Eine “Race Condition” tritt z. B. dann auf, wenn der Lock-Vorgang nicht
atomar ist. Also z. B. dann, wenn ich mit Lock-Dateien arbeite:
Prozess A prueft, ob die Datei vorhanden ist. Sie ist noch nicht
vorhanden und deshalb geraet A in den kritischen Bereich, wird dann
aber vom Scheduler schlafen gelegt um mit Prozess B fortzufahren.
Prozess B prueft dann auch, ob eine Lock-Datei vorhanden ist und
geraet auch in den kritischen Bereich. Beide legen eine Lock-Datei
an (auch eine nicht-atomare Operation). Wer hat nun den Lock?der letzte eben. Aber deswegen wird bei mir _vor_ dem Auslesen gelockt
und vor dem Schreiben nochmal nachgesehen.Tjor, aber das hilft dir nichts, wenn die Nachgucken-Funktion und das
anlegen des Locks, also beide Funktionen zusammen, nicht atomar sind :)Whatever, ich red dir da nicht rein, aber wenn es kaputt geht, musst du
dich auch drum kuemmern *gg*Ich wuerde mir das ueberlegen.
Im Moment lieber nicht. [...]
_Mir_ fliegt es ja nicht um die Ohren :)wußte gar nicht, daß die SELF-Server explosiv sind ;-)
sieh Dir die Funktionen an, wenn es bei Dir ist, und wenns wirklich
zu grottenschlecht sein sollte, kannst Du ja immer noch meckern.Ich meckere ja gar nicht, ich merke nur an, dass selbstgeschriebene
Locking-Funktionen einem oft um die Ohren fliegen. Ohne einen Semaphore
wuesste ich jetzt auch nicht, wie ich das machen sollte.Ich bitte auch zu bedenken, daß das Projekt in meinem Forum immer
zur Diskussion stand und die Beteilligung der Devs etwa 0 war.
Tut mir leid, aber davon habe ich nichts mitbekommenwie dem auch sei. Verstehe bitte, daß ich einfach anfangen wollte und
den Eindruck hatte, Diskussion ist da nicht sonderlich erwünscht. War
mir auch nicht danach, euch immer wieder mit Mails zu nerven.Du, du bist der Programmierer :) Wie du das handhabst ist deine Sache. Da
rede ich dir nicht drein.再见,
CK--
Ihr wisst nicht, wie man den Menschen dient. Wie sollt ihr wissen, wie man den Goettern dienen soll?
http://wwwtech.de/-
der letzte eben. Aber deswegen wird bei mir _vor_ dem Auslesen gelockt
und vor dem Schreiben nochmal nachgesehen.Tjor, aber das hilft dir nichts, wenn die Nachgucken-Funktion und das
anlegen des Locks, also beide Funktionen zusammen, nicht atomar sind :)hmm... ich kümmere mich mal noch um das vorher beschriebene Zeitfenster - kommt mir sehr intelligent vor, wie so manche meiner Ideen zu Anfang ;-) Es bindet auch Locking und Nachgucken zu einer Sache zusammen. Vielleicht ist das ja "atomar" genug :-)
Du, du bist der Programmierer :) Wie du das handhabst ist deine Sache. Da
rede ich dir nicht drein.fein. Dann mache ich das erstmal so und wenn sich Weiterbildung ergeben hat, werde ich das mal weiterentwickeln/ändern.
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch-
你好 Andreas,
der letzte eben. Aber deswegen wird bei mir _vor_ dem Auslesen gelockt
und vor dem Schreiben nochmal nachgesehen.Tjor, aber das hilft dir nichts, wenn die Nachgucken-Funktion und das
anlegen des Locks, also beide Funktionen zusammen, nicht atomar sind :)hmm... ich kümmere mich mal noch um das vorher beschriebene
Zeitfenster - kommt mir sehr intelligent vor, wie so manche meiner
Ideen zu Anfang ;-) Es bindet auch Locking und Nachgucken zu einer
Sache zusammen. Vielleicht ist das ja "atomar" genug :-)Hehe. Solange du nicht sicherstellen kannst, dass zwischen den zwei
oder sogar waehrend der zwei Operationen _nichts_ passieren kann, der
Lock also _wirklich_ atomar ist, sorgt Murphy dafuer, dass dir das Ding
irgendwann um die Ohren fliegt *g* Ja, ich weiss, der war ein Ar***loch :)Das ist jetzt mehr FYI, wenns dich also nicht interessiert, ueberliess es
halt. Auf einem Multiprozessorsystem kann es sogar sein, dass nichtmal
das kopieren eines Word in den Speicher atomar ist. Waehrend der eine
Prozessor den Wert schon geschrieben hat (damit ist er dann im Cache
gelandet) liest uU der zweite Prozessor noch den alten Wert aus. Alles
sehr vertrackt und ueberhaupt nicht trivial.再见,
CK-
Hehe. Solange du nicht sicherstellen kannst, dass zwischen den zwei
oder sogar waehrend der zwei Operationen _nichts_ passieren kann,daß ein Anderer aus demselben System schreibt oder liest verhindere ich schon... Andere sollten auf die Dateien schreiben gar nicht zugreifen.
naja, das ist wie mit der Benutzung des Bürgersteigs. Da kann ich auch nicht sicherstellen, daß nicht ein Verrückter Autofahrer auf den Bürgersteig prescht und mich umnietet. Trotzdem riskiere ich es manchmal - z.B. zum Einkaufen gehen, manchmal sogar für so unnützes Zeugs wie spazieren gehen ;-)
Lock also _wirklich_ atomar ist,
ich prüfe aber nachher, ob ein anderer gelockt hat und habe ihm dies nur innerhalb einer bestimmten Zeit zugelassen. Sollte sicher sein :-)
Allessehr vertrackt und ueberhaupt nicht trivial.
glaub ich ja :-)
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch
-
-
-
-
hi,
Dir ist klar, dass die Datei nur zur Laufzeit gesperrt ist? Ist das
Script beendet, ist auch der Lock aufgehoben.
ich habe deshalb in die Testdatei ein sleep() eingebaut. Ob das nun zur
Laufzeit zählt, weiß ich nicht.
Jepp, tut es.sleep ist schon mal ganz schlecht :)
demnach hätte sich bei den Tests aber für den jeweils zweiten Aufruf innerhalb dieser Zeit ein "schon gesperrt" ergeben müssen...
atomar ist. Also z. B. dann, wenn ich mit Lock-Dateien arbeite: Prozess A
prueft, ob die Datei vorhanden ist. Sie ist noch nicht vorhanden und
deshalb geraet A in den kritischen Bereich, wird dann aber vom Scheduler
schlafen gelegt um mit Prozess B fortzufahren. Prozess B prueft dann auch,
ob eine Lock-Datei vorhanden ist und geraet auch in den kritischen Bereich.
Beide legen eine Lock-Datei an (auch eine nicht-atomare Operation). Wer
hat nun den Lock?der letzte eben. Aber deswegen wird bei mir _vor_ dem Auslesen gelockt und vor dem Schreiben nochmal nachgesehen. Wenn ein fremd-Prozess den Lock überschreibt, kann der erste nicht mehr schreiben. Es müßte schon passieren, daß beide eine leere lockdatei finden, A schreibt den Lock, liest die Hauptdatei aus, verändert die Daten, kontrolliert die Lockdatei: o.k. Und _danach_ erst schreibt B die Lockdatei zurück und darf die Hauptdatei lesen. Wenn jetzt A die Hauptdatei zurückschreibt liest B vielleicht was Falsches aus.
ja,aber B sollte kein zugriff auf irgendwelche prozesse haben,wo A grade am lesen und schreiben ist.Ich würde A solange den Lock geben bis das file geschlossen ist und erst dann B weiter laufen lassen ohne sleep...ist doch viel einfacher so.
datei zum lesen und schreiben öffnen locken datei schliessen -> und jetzt darf prozess B weiter machen.
Wenn Du sicher gehen willst dass keine datenverluste entstehen durch lesen und schreiben,dann würde ich auf jedenfall LOCK_EX verwenden für lesen und schreiben und mit close (file) beenden,was den lock aufhebt.Auf keinen fall mit unlock arbeiten.http://forum.de.selfhtml.org/archiv/1999_4/t07970.htm steht noch was...
Grüsse
Alain
-
-
-
-
-
-
-
-
-
ach, ich dachte das verwendet nur [a-zA-Z0-9]. Hat bei mir jedenfalls noch nichts anderes gemacht.
naja, in PHP scheint das auch so zu sein: "md5(str) Berechnet den MD5-Code von str unter Verwendung des RSA Data Security, Inc. MD5 Message-Digest Algorithm, und gibt das Ergebnis zurück. Dieser Code ist eine hexadezimale Zahl mit 32 Zeichen Länge. "
Gruß, Andreas
--
SELFFORUM - hier werden Sie geholfen,
auch in Fragen zu richtiges Deutsch
-
-
hi CK,
dann hab ich einen schönen namen ohne sonderzeichen wie "/" (der ja auch
vorkommen könnte durch crypt)einfacher bekommst Du wie schon erwähnt einen Sonderzeichenfreien String
mit md5.Naja, md5 macht einfach nur eine Hash-Summe von 16x1 Byte. Du musst
das schon Hex-codieren, damit da was sonderzeichenfreies dabei rauskommt :)Meine frage diesbezüglich:
$crypttext =~ s/[^A-Za-z]//g; bedeutet doch dass alles ausser
gross und klein buchstaben (weil "[^]")durch nichts ersetzt werden,warum sollte ich da jetzt noch was packen?
Grüsse
Alain-
你好 Alain,
Meine frage diesbezüglich:
$crypttext =~ s/[^A-Za-z]//g; bedeutet doch dass alles ausser
gross und klein buchstaben (weil "[^]")durch nichts ersetzt werden,warum
sollte ich da jetzt noch was packen?Hab ich doch gar nicht gesagt? Auf deinen Beitrag bin ich doch gar nicht
eingegangen :)再见,
CK--
Descartes sagte: 'Ich denke, also bin ich.' Ich hingegen sage: 'Ich denke nicht, also bin ich.'
http://wwwtech.de/
-
-
-
-
-
-
-
-
Moin!
(mein shop ist nicht gerade besucherfreudig :) )
Oh oh! Was, wenn sich das mal ändert? Genau genommen ist diese Veränderung doch sicherlich gewünscht und sollte genau deshalb berücksichtigt werden.
Mein Vorschlag: Setze ein Sitzungscookie, also eines _ohne_ Gültigkeitsangabe. Ein Besucher, der seinen Browser sinnvoll konfiguriert hat, lässt diese Sitzungscookies immer zu. Damit verlierts Du die wenigsten Kunden, falls Du Dir die Arbeit mit der Weitergabe der Session in jeder URL und jedem Formular nicht machen willst (selbst das liese sich durch einen Ersetzungsvorgang vor dem print() "automatisieren").
Zudem birgt die Weiergabe der Session-ID in der URL auch ein eigenens Sicherheitsproblem: es wird im sogenannten Referer weitergegeben, also auch beim Einbinden externer Grafiken oder nach Klick auf einen externen Link.
MFFG (Mit freundlich- friedfertigem Grinsen)
fastix®
--
Als Freiberufler bin ich immer auf der Suche nach Aufträgen: Schulungen, Development. Auch für seriöse Agenturen.
-
-
-
-
-