nicht angemeldet
Hallo Michael!
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.
Wahnsinn - bis dato war ich doch wirklich so naiv anzunehmen, das ich darauf vertrauen kann, ausser ich habe einen Opera-Besucher der sich anders ausgibt. Man lernt wirklich nie aus!
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.
Ja, könnte er. Dann fällt das weg für mich, da ich auch Besucher mit deaktivertem JavaScript nicht ausschließen möchte.
- 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
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.
Jetzt dachte ich gerade wir sprechen doch von etwas ganz verschiedenem, aber ich denke so ist es gar nicht.
Ich dachte daran, den Film nur dann zu löschen, wenn er einmal zurückgeht und dann aber einen anderen Link anklickt als den, den ich von ihm grundsätzlich erwarte (also den letzten Eintrag in der Filmtabelle) - meine Basisüberlegung waren dabei andere Seiten als direkt der Warenkorb.
Im Prinzip ist es beim Warenkorb nichts anderes, den hier breche ich meinen Film ja genauso ab, wenn er z.B. die Menge einer Warenkorbposition ändert, als wenn ich auf einer anderen Seiten auf einen Link klicke.
Der Besucher nimmt sich dabei selbst die Möglichkeit die Seiten die er über den Back-Button zurückgesprungen ist über Vorwärts wieder aufzurufen und wenn das der Fall ist kann ich Einträge der Filmtabelle löschen. So nur mal meine theoretischen Gedanken, ich werde mich jetzt einmal ans Programmieren machen, um zu sehen ob meine theoretischen Vorstellungen in der Praxis auch so laufen, wie ich es mir denke.
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. Dieser lernt auf
diese Weise, daß es auch in seinem eigenen Interesse
ist, sich ordentlich abzumelden ...
Ist klar, dies ist aber fürs erste nicht vorgesehen. Der Kunde hat (siehe b) natürlich die Möglichkeit den Warenkorb ganz zu entleeren. Mein Kunde will ihm aber zusätzlich nicht die Möglichkeit "aufs Aug drücken" jederzeit abbrechen zu können.
b) Wenn er den Warenkorb löscht -
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.
Ok, soweit verstanden.
c) Wenn er im Bestellvorgang abbricht - denke ich
sollte ich wohl die Transaktion noch nicht
beendigen, oder? Um das zu beurteilen, weiß ich nicht genug über den
genauen Dialog - das mußt Du selbst entscheiden.
Ja, Ok. Für mich ist es sinnvoller ihm dann seine Daten zu lassen.
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. ;-)
Das ist klar. Ich sehe das Ganze für mich auch als Diskussion für die Zukunft, auch wenn ich alles was ich durch deine Unterstützung nun dazugelernt habe, vielleicht nicht im aktuellen Projekt umsetzen werde können, obwohl dies sicherlich zu einem großen Teil der Fall sein wird, da auch meinem Auftraggeber die Sicherheit sehr wichtig ist.
Mir ist es einfach wichtig, mich weiterzuentwickeln, für mich die Möglichkeiten und Grenzen abstecken zu können und mir Gedanken darüber zu machen, was ist unabdingbar, was ist möglich und was nicht. Denn nur so kann ich meiner Meinung nach kompetent beraten und argumentieren. Für mich ist das sehr wichtig - nicht nur beim Thema Sicherheit sondern allgemein bei meiner Arbeit. Wenn ich das nicht tun würde, denke ich mir, kann ich mich gleich der Gemeinde der "Frontpage-Webdesigner" anschließen :).
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.
Ach ja, dann wäre hier wohl beispielsweise eine HEAP-Tabelle zu empfehlen ...
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 ... ;-)
Ich würds auch nicht glauben an deiner Stelle :)
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!
Freut mich, dass du das so siehst.
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.
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.
Ist klar.
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.
Ist eigentlich logisch. Das hat meine Gehirnwindungen wieder etwas entwirrt ...
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?
Wenn Deine Kunden sich etwas davon versprechen
können, sich präventiv angemeldet zu haben, dann
tun sie das auch - wenigstens einige von ihnen.
Ja, da hast du Recht. Auf so etwas in der Richtung habe ich auch schon gedacht. Mal schauen, was mein Auftraggeber dazu sagt.
Lieber Michael, ich danke dir sehr für deine Anregungen, Tipps und deine Hilfe. Ich werde nun mal mein dank dir neu erworbenes Wissen in die Praxis umsetzen.
Danke, liebe Grüße und viel Erfolg bei deiner Arbeit!
Sabine
Viele Grüße
Michael