nicht angemeldet
Hallo Sabine,
wäre meine nächste Idee, ein Programm wie meinen
HTTP-Tracer zu nehmen, also einen Roboter als
HTTP-Client. Diesen so zu schreiben, daß er HTTP
bedienen kann, ist verhältnismäßig einfach -
Puh, das wusste ich nicht.
Nimm Dir mal
http://www.schroepl.net/cgi-bin/http_trace.pl
als Beispiel - das Ding reicht Deine HTTP-Requests
einfach nur durch, aber es wäre trivial, definierte
Änderungen am HTTP-Header durchzuführen, also
beispielsweise den UserAgent zu fälschen.
Ich verwende zwar Javascript (Mouseover-Grafiken),
allerdings funktioniert die Seite auch ohne
Javascript.
Hilft mir das dann was, weil ich dann vom HTTP-
Tracer verlange sich irgendwie zu deklarieren -
also ich verwende Javascript oder ich verwende es
nicht?
Nein. Wenn Du JavaScript nur für "nice to have"
verwendest, wird der Robot problemlos "korrekte"
HTTP-Requests erzeugen können.
Würdest Du beispielsweise mit JavaScript URL-Teile
in Links bzw. Formularen manipulieren, dann sähe das
anders aus.
Frage Dich einfach mal, ob ein Links-Checker durch Deinen Shop-Dialog hindurchlaufen könnte oder nicht.
- Mein Besucher surft auf meiner Website herum
- Er führt irgendeine Aktion aus, klickt auf einen
Link, einen Submit-Button oder geht z.B. Back.- Ich überprüfe, ob ich die Kombination Timestamp
+ SessionID von ihm habe- Ich überprüfe, ob die SessionID seine sein kann
(z.B. User-Agent)- Wenn es um den Warenkorb geht überprüfe ich
zusätzlich ob er einen bestehenden Eintrag des
Warenkorbs verändert hat- Wenn die Prüfungen alle Ok waren, darf er weiter
Wobei er als Antwort eine Seite bekommt, die eventuell
einen bereits vorhandenen timestamp haben kann -
nämlich genau dann, wenn der empfangene timestamp im
Film gefunden wurden und Test Nr. 5 ebenfalls positiv
ausfiel.
Andernfalls (Test 5 negativ) bekommt er eben eine neue
Seite mit einem neuen Timestamp, und der alte Film wird
ab dieser Stelle gelöscht.
Wenn jetzt der User z.B. zurückgegangen ist auf
timestamp 1 generiere ich 1. einen neuen
Datenbankeintrag (timestamp 5), den ich
grundsätzlich als nächstes von ihm erwarte
(wenn er auf einen Link klickt).
Warum schon jetzt?
Wenn er zurück gegangen ist auf timestamp 1, wirst
Du ihm eine Seite mit timestamp 2 senden wollen.
Er soll ja innerhalb des existierenden Films vor und
zurück blättern können - und eventuell auch wieder
vorwärts springen.
Wenn er den Inhalt des dabei gesendeten Formulars
tatsächlich ändert, dann wirst Du das bei Test 5
nach dem Empfang der Seite mit Timestamp 2 merken.
Bei explizit abgebrochen komme ich nun nicht ganz
klar
Es könnte ja sein, daß Du in jeder Seite einen Button
"gesamte Aktion abbrechen" drin hast.
Du hast zwar keine Garantie, daß der Benutzer diesen
Button wirklich betätigt, aber Du kannst ihm die
Gelegenheit dazu ja wenigstens mal geben.
Bei Online-Banking gilt manchmal als zusätzliche
Sicherheitsmaßnahme, daß mehrfaches gleichzeitiges
login nicht möglich ist. Wenn ein Anwender seinen
Browser schließt, ohne sich abzumelden, und sich
sofort wieder anmelden will, kommt es bei bestimmten
Banken vor, daß diese eine Anmeldung für eine bestimmte
timeout-Phase sperren - um beispielsweise das
Durchprobieren von Passworten zu verhindern oder
Ähnliches.
In Deinem Fall könntest Du etwas Ähnliches einbauen
wollen - beispielsweise die Kombination aus IP-Adresse
und UserAgent (oder was auch immer) eine bestimmte Zeit
lang sperren, nachdem eine Transaktion mit diesen Daten
offensichtlich "kaputt gegangen" ist, und das mit einer
erklärenden Meldung an den Anwender. Dieser lernt auf
diese Weise, daß es auch in seinem eigenen Interesse
ist, sich ordentlich abzumelden ...
b) Wenn er den Warenkorb löscht - Ok ist mir klar,
dann kann ich die Transaktionen löschen und ihn von
vorne beginnen lassen
Yep - auch das ist ein Fall, in dem Du den Film früher
los wirst als nach Deinem timeout.
Jede Chance, diese Datenmenge frühzeitig zu reduzieren,
darfst Du gerne mitnehmen.
c) Wenn er im Bestellvorgang abbricht - denke ich
sollte ich wohl die Transaktion noch nicht
beendigen, oder? Meinem Besucher ist vielleicht grad
eingefallen, dass er doch noch was bestellen oder
etwas aus dem Warenkorb entfernen möchte und er geht
nochmal zurück, dann sollte ich ihm aber wohl
sinnvollerweise seine Daten noch erhalten.
Um das zu beurteilen, weiß ich nicht genug über den
genauen Dialog - das mußt Du selbst entscheiden.
Ok, dankeschön für die Info. Das beruhigt mich.
Nach vielen Antworten dachte ich wirklich schon
was mir heute jemand geschrieben hat, dass ich ein
Sicherheitsfanatiker bin und womöglich mit Kanonen
auf Spatzen schieße.
Der Sinn dieser Diskussion ist doch gerade, zu
erkennen, welche Maßnahmen welches Preis-/Leistungs-
Verhältnis mit sich bringen.
Da ist es eine gute Ausgangssituation, erst mal hyper-
mißtrauisch zu sein - besser jedenfalls als zu leichtsinnig ... was von alledem Du später tatsächlich
realisieren wirst, dürfte nicht zuletzt davon abhängen,
was Dein Auftraggeber zu bezahlen bereit ist. ;-)
Vielleicht läßt sich diese Tabelle ja komplett
im Hauptspeicher halten?
(Das wäre ein Tuning-Job für den DB-
Administrator.)
Das wird nicht gehen, da ich hierauf keinen Zugriff
habe (externer Server). Habe ich als "normaler
Besitzer" einer DB bei einem Fremdhoster die
Möglichkeit die Filmtabelle in einem performanteren
Modus laufen zu lassen? Wenn ja, kannst du mir
vielleicht ein Stichwort dazu geben, womit ich mich
hier beschäftigen sollte?
Bei mySQL ist das beispielsweise schon eine Eigenschaft
des verwendeten Tabellentyps.
Was genau Du an Einflußnahme hast, ist natürlich
abhängig von Deinem Provider - aber Du kannst Deinem
Auftraggeber gegenüber auf jeden Fall mal erwähnen,
daß diese beiden Tabellen(Film und Archiv) erheblich
unterschiedliche Änderungsraten haben werden, so daß
sich eine unterschiedliche Behandlung innerhalb des
RDMBS lohnen könnte.
Sollte dann später ein Lastproblem entstehen, weißt Du
wenigstens, wo man ansetzen könnte - falls nicht, war
es halt eine Information mehr, die an anderer Stelle
vielleicht mal etwas helfen kann.
Abschließend habe ich (wie könnte es auch anders
sein) noch eine Frage - ich verspreche es, jetzt
hast du dann bald Ruhe von mir,
Tststs ... ;-)
aber ich freue mich total, endlich mit jemanden
darüber "diskutieren" (bzw. jemanden dazu löchern
:)) zu können, was schon die ganze Zeit in meinem
Gehirn herumbraust.
Ich doch auch - verglichen mit den diversen 2-Frames-Fragen oder den verzweifelten Versuchen, dem Anwender
seinen Browser zu verstümmeln, ist dieser Thread eine
erfreuliche Abwechslung!
Wenn mein Besucher nun beschließt das zu bestellen,
was er in den Warenkorb gelegt hat,
a) registriert er sich, wenn er ein neuer Kunde ist
b) loggt sich ein, wenn er ein bestehender Kunde ist
soweit alles klar, er kann aber jederzeit wieder aus
dem Bestellvorgang rausgehen - ist es dann
empfehlenswert ihn aus Sicherheitsgründen, wenn er
dann doch wieder bestellen will, nochmals einloggen
zu lassen oder ihn als eingeloggt gespeichert
lassen.
Wie genau steht das zu verwendende Verfahren zum
Einloggen bereits fest?
Deine Frage zielt auf Usability; ich kann an dieser
Stelle nicht für Deine Kunden sprechen, sondern
höchstens kommentieren, mit welchem Verfahren Du
welche Freiheitsgrade hättest.
Was ist größer, die Gefahr ihn zu verärgern wenn
er wieder einloggen muss oder das Risiko einen
Fremdangriff - dann allerdings in einen kritischeren
Bereich aufgrund seiner personenbezogenen Daten zu
haben?
Wenn Du ein Login-Verfahren verwenden kannst, das auch
beim Zurück-Gehen erhalten bleibt (Server Authentica-
tion bzw. Cookie), besteht das Problem gar nicht.
Wenn die Authentifizierung aber Bestandteil Deiner
Session-ID ist, also im Query-String Deiner URLs
steckt, dann ist ein Schritt zurück und ein neuer
Anlauf in Richtung erfolgreichem Abschluß der Trans-
aktion eine echte Zeitreise, bei der Deine Links das
Wissen um die (zeitlich später liegende) Anmeldung
verloren haben - da dürftest Du einfach keine Chance
haben.
Vielleicht kannst Du Deine Stammkunden ermutigen,
sich bereits zu Beginn der Transaktion anzumelden -
beispielsweise dadurch, daß angemeldete Besucher
irgendwelche Zusatz-Features während des Dialogs
bekommen?
Dein "Kunden-Gedächtnis" könnte beispielsweise die
Information besitzen, was dieser Kunde bisher schon
alles gekauft hat, und ihn auf aktuelle Angebote
vergleichbarer Produkte hinweisen ... ungefähr das,
was viele Webseiten mit Cookies probieren.
Oder vielleicht kann ein angemeldeter Besucher
dauerhafte irgendwelche Konfigurationen vornehmen,
beispielsweise eine bestimmte, ihm genehme Dar-
stellungsform der Dialogführung, so daß die Seiten
bei jedem Kunden dessen Vorlieben entsprechend
aussehen?
Wenn Deine Kunden sich etwas davon versprechen
können, sich präventiv angemeldet zu haben, dann
tun sie das auch - wenigstens einige von ihnen.
Viele Grüße
Michael