USER-ID: Wie wahrscheinlich ist es....

[Christian Schnagl]

Hallo Forum,

ich habe einen Warenkorb programmiert, der ohne JAVAscript funktionieren soll.
Zur User-Identifizierung verwende ich

1. Einen User-String bestehend aus:
REMOTE_ADDR, HTTP_USER_AGENT, HTTP_ACCEPT

2. Ein Verfallsdatum von 3 Stunden (alle Produkte, die länger als 3 Stunden im Warenkorb sind, werden nicht mehr angezeigt)

Wegen der Probleme bei REMOTE_ADDR (Proxy, masquerade, etc...) verwende ich nur die ersten drei Zahlen der IP-Adresse (aus 101.102.103.104 wird 101.102.103)

MEINE FRAGEN:

Glaubt Ihr, daß dies ausreicht? Oder anders herum: Wie wahrscheinlich ist es, daß zwei User zur gleichen Zeit (innerhalb 3 Stunden) mit dem gleichen User-String auf den Warenkorb treffen? (ca. 200 User !!! pro Tag)

Gibt es eine andere Möglichkeit SERVERSEITIG dem USER eine ID zu verpassen? (HTML und CGI gemischt, also nix mit Parameterübergabe)

Danke im Vorraus

Christian Schnagl

[Reiner Rusch]

Hallo Christian,

ich würde das so nicht machen!
Es ist durchaus wahrscheinlich, daß in den 3 Stunden zwei Leute durch den gleichen Proxy latschen!

Nimm' besser Cookies!

Mit:
wert=jetzt.getTime();

Setzt Du einen Wert, der -meiner Meinung nach- eindeutig ist. Es handelt sich um die Zeit in Millisekunden, die seit dem 1.1.1970 vergangen ist. Es ist rel. unwahrscheinlich, daß zwei Leute genau den gleichen Wert bekommen!

Alles Gute,
Reiner

[Christian Schnagl]

Hallo Reiner,

Es ist durchaus wahrscheinlich, daß in den 3 Stunden zwei Leute durch den gleichen Proxy latschen!

ja, aber haben Sie dann auch den gleichen Browser (Version, Sprachversion) und die gleiche Software installiert (bei HTTP_ACCEPT steht immer etwas anderes Word, Excel oder */* etc...)   ???

Nimm' besser Cookies!

Danke, aber die Kriterien "OHNE JAVASCRIPT" und "SERVERSEITIG" werden damit nicht erfüllt.

Gruß,
  Christian Schnagl

[Tom]

Hallo Christian

Es wird kaum ein Weg daran vorbeiführen, dass Du Serverseitig eine Sesion-ID generierst (aus getTime() ** Prozess-ID, dieser Wert ist mit sehr hoher Wahrscheinlichkeit eindeutig) und diese in irgendeiner Form im Client ablegst.
Wenn dabei Javascript und Cookies nicht in Frage kommen, kannst Du mit einem hidden-Formularfeld in jeder HTML-Seite die Sesion-ID von Seite zu Seite übertragen (oder im HTML-Dokument des Warenkorbes verstecken).

Dein Vorschlag von eine Kombination aus HTTP_ACCEPT, REMOTE_ADDR und HTTP_USER_AGENT ist vor allem bei Usern aus Firmennetzen untauglich, da dort mit Firewall/IP-Filtering gearbeitet wird und auf den einzelnen Rechnern Standardinstallationen aufgebaut werden, um die Systemadministration zu erleichtern.

Also bleibt wohl nur der komplizierte Weg über Sesion-ID oder so was ähnliches .. ;-(

Natürlich hoffe ich für Dich, dass ich mich irre... (aber eine andere Idee habe ich nicht).

Grüsse

Tom

[Michael Schröpl]

Wie wahrscheinlich ist es, daß zwei User zur gleichen Zeit (innerhalb 3 Stunden) mit dem gleichen User-String auf den Warenkorb treffen? (ca. 200 User !!! pro Tag)

Ich würde eher überlegen, was alles passieren kann, wenn der Fall doch eintritt.
Wenn Dir jemand Böses will, loggt er sich nämlich bewußt zweimal mit derselben Kennung und demselben Browser ein, nur um zu sehen, was er dann alles umsonst einkaufen kann ... :-)

[Christian Schnagl]

Hallo Michael,

Wenn Dir jemand Böses will, loggt er sich nämlich bewußt zweimal mit derselben Kennung und demselben Browser ein, nur um zu sehen, was er dann alles umsonst einkaufen kann ... :-)

Umsonst wohl kaum, da ja ohne eine Adresse kein Versand von Waren stattfinden kann. Die Gefahr ist eher, daß jemand etwas erhält, was er gar nicht bestellt hat...

Gruß
  Christian Schnagl

[Roman Pfarrhofer]

Hallo Christian!

Ich bin mit deinen wagen IP-Geschichten nicht sehr glücklich. Das ist viel zu unsicher. Ich habe ja auch schon mal einen Shop gemacht und mir mehrere Lösungsansätze überlegt. Das Ergebnis ist eine komplett serverseitige Lösung, also auch ohne JS+Cookies.

Ein Benutzer kann sich alles Anschauen, nur sobald er etwas in den Warenkorb legen will muß er sich registrieren. Daten kommen in die DB und aus einigen Werten wird mit einer MD5 Verschlüsselung ein ID erzeugt, der dann immer zw. den Seiten übergeben wird. Warenkorb wird auch von der Datenbank verwaltet. Wenn ein User wiederkommt kann er entweder seine Benutzerinfos (eMail + Pwd) gleich eingeben oder wenn er wieder etwas in den Warenkorb legen will.

Vorteile:

• großer Kundenstamm (auch Kunden die noch nie was bestellt haben)
• Warenkörbe werden über Sitzungen erhalten
• Möglichkeit von der Personalisierung (persönliche Farbeinstellungen, abos von News...)
• keine Probleme mit Usern die auf dem selben PC arbeiten (z.B. mit Cookies in Schulen - mehr User als PCs)
• und jeder Benutzer ist EINZIGARTIG

Nachteil:

• Benutzer wird durch Registrierung vielleicht abgeschreckt

Wenn du es dir mal in Aktion ansehen willst: http://www1.libro.at/

CU Roman