Auf einen Buttonklick reagieren

[Marco1174]

Hallo zusammen.

ich hab ein prob. ich will über asp auf einen buttonklick reagieren. sowie in vb onclick oder so. das prob ist das. ich hab eine eingabemaske. wenn alle felder gefüllt sind, drückt der user auf absenden. wenn dies erfolgt ist, sollen dann die daten eben versendet werden. aber dies darf nur einmal passieren. wie kann ich das abfangen dass der nicht 30 mal klicken kann und jedesmal die daten versendet werden?? hört sich bestimmt alles total doof an, aber ich hab eben nicht die grosse ahnung von dem was ich hier mache. also vielleicht kann mir jemand helfen. bitte die antowrten an folgende email: orso.m@snafu.

danke junx und mädels

euch allen ein schönes fest und frohes neues jahr

[Impulz]

Hi,

da ASP eine server-basierte Sprache ist, kannst du nicht direkt auf einen Button-Click reagieren, sondern musst stattdessen client-seitig ausgeführte Scriptsprachen (JavaScript, VBScript, ..) benutzen wenn du Klicks gesondert behandeln willst.

Um zu verhindern dass jemand mehrfach hintereinander auf einen Button klickt, koenntest du beispielsweise in der Session ein Flag setzen, dass die Daten bereits abgeschickt wurden und alle neu ankommenden Daten verworfen werden.

Frag mich bitte nicht wie/ob in ASP sessions gehen, ich hab keine ahnung *g* Bei php gehts recht einfach, also vermute ich mal dass es bei ASP auch nicht unbedingt so aufwendig sein wird.

Michael

[alligator]

Hi.

Ich kenne mich in ASP auch nicht aus, aber falls es in ASP möglich ist, dann speichere doch die IP deines User nach dem Klick auf "abschicken" und überprüfe auf die, so dass wenn man mit dieser IP nochmal auf "abschicken" klickt, dann die Meldung kommt, das er es schon abgeschickt hat ...

cu

alligator

[Buhu]

Hallo !

Wenn ich ein Formular über ASP erstelle, dann schicke ich beim Senden den User über eine reine Funktionsseite, bei der die Daten aus dem Formular ausgelesen werden. An dieser Stelle kann auch geprüft werden, ob die selben Daten mehrmals gesendet wurden.

Man kann aber auch auf der Funktionsseite den Befehl response.redirect verwenden, und damit nach dem Ausführen eine ganz andere Seite aufrufen. Oder man öffnet damit wieder die Formularseite. Die Eingabefelder sind dann leer.

Ich hoffe, ich konnte weiterhelfen.

:WD

[DanielH]

Hi,

wenn auf abschicken geklickt wird, kannst du doch ein Clientseitiges Script aufrufen, welches prüft ob das Feld gefüllt ist, und wenn ja, wird es nach dem versenden gelöscht.

Es bedarf schon einer Menge "bösen Willen" ein Formular 30 mal auszufüllen um es 30 mal zu versenden

MfG

[lapso]

Original geschrieben von alligator

Hi.

Ich kenne mich in ASP auch nicht aus, aber falls es in ASP möglich ist, dann speichere doch die IP deines User nach dem Klick auf "abschicken" und überprüfe auf die, so dass wenn man mit dieser IP nochmal auf "abschicken" klickt, dann die Meldung kommt, das er es schon abgeschickt hat ...

cu

alligator

Ganz schlechte Idee.

Besser (aber auch nicht ideal): Das Formular mit einer ID versehen. Wird die ID ein zweites mal verwendet, einfach verweigern.

gruss

matze

[alligator]

Hi.

@lapso

Hmm jetzt bin ich aber mal gespannt mit welcher erklärung?

cu

alligator

[lapso]

Original geschrieben von alligator

Hi.

@lapso

Hmm jetzt bin ich aber mal gespannt mit welcher erklärung?

cu

alligator

Was meinst du genau? Der Ausschluss über die IP-Adresse?

Banale Antwort: DHCP und/oder NAT. Eine IP-Adresse kann nicht mit einem User gleich gesetzt werden. Es ist ja durchaus möglich, dass 1024-einhalb User auf einer einzigen IP-Adresse surfen. Oder auch sehr üblich: Die IP-Adresse gehört eine Minute dem einen User, in der nächsten Minute schon einem anderen.

Wie willst Du diesen (überspitzten) Realitäten mit IP-Adress-Sperren gerecht werden?

Grüße

Matze

[alligator]

Ich denk ehrlichgesagt, das das zu vernachlässigen ist.

Kuck mal die meisten Reloadsperren bei nem Counter sind mit IP.

Du speicherst ja nicht die IP für immer, sondern nur bis zur nächsten IP. Halt wie bei einem Counter ....

Und das ist einmal weniger Programmieraufwand (einfacher) und zum anderen denke ich auch trafficsparender ...

cu

alligator

[lapso]

Original geschrieben von alligator

Ich denk ehrlichgesagt, das das zu vernachlässigen ist. Kuck mal die meisten Reloadsperren bei nem Counter sind mit IP. Du speicherst ja nicht die IP für immer, sondern nur bis zur nächsten IP. Halt wie bei einem Counter .... Und das ist einmal weniger Programmieraufwand (einfacher) und zum anderen denke ich auch trafficsparender ...

cu alligator

Das kann ich überhaupt nicht bestätigen.

1. bleibt stets das Problem mit NAT, also mehreren Surfern auf einer IP. Das ist sehr gängig, in vielen Unternehmen. Das Problem steht und will nicht durch Ignorieren verschwinden.

2. Counter sind bei weitem nicht so relevant wie Form-Sperren und sollten daher wohl auch nicht als Vorlage heran gezogen werden. Wenn übrigens ein Counter das wie beschrieben implementiert, dann ist der Counter nicht besonders dolle (manche nennen es Pfusch vor dem Herrn).

3. Traffic sollte wohl nicht ausschlag gebend sein. Wir bewegen uns im Bereich von wenn überhaupt wenigen KBytes. Wirklich Traffic würden wir durch das Weglassen des Forms sparen

4. Wie lange will man eine IP sperren? 5 Minuten? Der Typ holt sich einen Kaffe, schnackt ne Runde mit der Praktikantin (olala) und schickt das Form nochmal ab. 1 Stunde? Der Typ ist offline, ein anderer geht mit der selben IP wieder rein, patz. Dynamische IPs werden von allen größeren Providern vergeben und stellen somit immer ein Problem dar.

5. Was heißt "nur bis zur nächsten IP"? Wenn ich eine wohlfrequentierte Seite habe, so haben schon wieder 50 weitere Surfer das Form besucht, während der erste es noch ausfüllt.

6. Eine Formsperre via ID ist in 30 minuten (wiederverwendbar) implementiert und sie in die Forms einzubauen ist nich schwerer als von einer Katze einen Kratzer zu bekommen.

Machen wir´s kurz: Eine IP ist nicht gleich eine Person, nichteinmal innerhalb von 5 Sekunden. Nungut, für eine private Seite mag das alles "vernachlässigbar" sein, nicht aber für eine professionelle. Stell Dir vor, bei BMW ist Mittach, und 500 Typen surfen via NAT-Router auf web.de: Der erste kommt rein und das war´s.

just my 2€cents

Gruß, Matze

[alligator]

Original geschrieben von lapso

Das kann ich überhaupt nicht bestätigen.

1. bleibt stets das Problem mit NAT, also mehreren Surfern auf einer IP. Das ist sehr gängig, in vielen Unternehmen. Das Problem steht und will nicht durch Ignorieren verschwinden.

Jo wäre schon ein Problem, wenn die Zielgruppe in einem Unternehmen arbeitet und nur Leute von da auf die Site surfen.

Aber dennoch denke ich das dies in den meisten kleinen bis mittelgroßen Auftritten zu vernachlässigen ist.

2. Counter sind bei weitem nicht so relevant wie Form-Sperren und sollten daher wohl auch nicht als Vorlage heran gezogen werden. Wenn übrigens ein Counter das wie beschrieben implementiert, dann ist der Counter nicht besonders dolle (manche nennen es Pfusch vor dem Herrn).

So ist jeder normale/gute Counter, denn alles andere ist Schnickschnack

3. Traffic sollte wohl nicht ausschlag gebend sein. Wir bewegen uns im Bereich von wenn überhaupt wenigen KBytes. Wirklich Traffic würden wir durch das Weglassen des Forms sparen

Wenige KBytes machen sich in der Perfomance & Traffic bei großen Auftritten schon bemerkbar ...

4. Wie lange will man eine IP sperren? 5 Minuten? Der Typ holt sich einen Kaffe, schnackt ne Runde mit der Praktikantin (olala) und schickt das Form nochmal ab. 1 Stunde? Der Typ ist offline, ein anderer geht mit der selben IP wieder rein, patz. Dynamische IPs werden von allen größeren Providern vergeben und stellen somit immer ein Problem dar.

Richtig. Und wie willste das mit deiner Session ID machen, wenn der Typ offline geht ... Haste das gleiche Problem.

Und es geht ja darum, das er nicht 30 mal hinterinander klickt und nicht, dass er es nur einmal abrufen kann für immer, wenn ich das richtig verstanden habe, denn das ist eh nicht machbar ...

5. Was heißt "nur bis zur nächsten IP"? Wenn ich eine wohlfrequentierte Seite habe, so haben schon wieder 50 weitere Surfer das Form besucht, während der erste es noch ausfüllt.

Hast schon recht, dann wäre das mit der IP auch Müll.

Aber dann könnte man ja die IP´s für 5 Minuten sperren oder so, dann wäre es egal wieviel andere draufkommen.

Aber ich denke eh nicht, dass diese Form so viele Surfer hat, denn sonst sollteman es nciht in ASP machen

6. Eine Formsperre via ID ist in 30 minuten (wiederverwendbar) implementiert und sie in die Forms einzubauen ist nich schwerer als von einer Katze einen Kratzer zu bekommen.

Möglich, kenne mich wie gesagt in ASP nicht aus ...

Machen wir´s kurz: Eine IP ist nicht gleich eine Person, nichteinmal innerhalb von 5 Sekunden. Nungut, für eine private Seite mag das alles "vernachlässigbar" sein, nicht aber für eine professionelle. Stell Dir vor, bei BMW ist Mittach, und 500 Typen surfen via NAT-Router auf web.de: Der erste kommt rein und das war´s.

ID ist aber ebenfalls nicht gleich Person, also hast du das gleiche Problem ...

Ich hab zwar noch nicht ganz verstanden wie du das technisch mit den ID´s machen willst, aber ich kann mir nicht ganz vorstellen, dass sovel besser sein soll, als mit IP´s ...

just my 2€cents

Gruß, Matze

cu

alligator

[lapso]

Aber dennoch denke ich das dies in den meisten kleinen bis mittelgroßen Auftritten zu vernachlässigen ist.

Wenige KBytes machen sich in der Perfomance & Traffic bei großen Auftritten schon bemerkbar ...

HA! Jetze habbich dich!

;-)

Aber ich denke eh nicht, dass diese Form so viele Surfer hat, denn sonst sollteman es nciht in ASP machen

Oh, das würde ich nicht behaupten. Auf jeden Fall sollte man es wohl nicht in PHP/mySQL machen, das ist wohl wahr. ASP/SQL-Server cruncht das aber auf jeden Fall, so man denn ASP korrekt zu programmieren weiß.

ID ist aber ebenfalls nicht gleich Person, also hast du das gleiche Problem ...

Naja, zumindest kannst du die ID mit einer Browser-Session in Verbindung bringen, also schon etwas persönlicher werden, als über eine in den endlosen Weiten des Netzes herumschwirrende IP.

Wichtig ist doch vor allem, eines zu verhindern:

- User füllt Form aus

- User schickt es ab

- INSERT in datenbank findet statt

- User clickt auf den back-button

- user schickt es nach korrektur nochmals ab

- zweiter INSERT findet statt.

und schon kocht die ... der Stuhl.

Da hilft eine Form-ID schon sehr gut, um nicht zu sagen: Exzellent. War der INSERT erfolgreich, gleich -schnippschnapp- die ID entwerten und gut is. Kein INSERT ohne gültige ID.

Sooo, und was mach ich nu als Projektarbeit? hmmmm.

Grüße

Matze

[alligator]

Naja das mit dem "Jetzt hab ich dich" waren zwei verschieden Ansatzpunkte ...

Aber mit deiner ID musst du doch ein Cookie setzen (oder zumindest sowas in der Art, weis ja nicht wie es in ASP ist)?

Und schon brumst du deinem User/Surfer auf, dass er die aktiviert haben muss, da es sonst nicht geht, Und schon kommt der Faktor Sicherheit ins Spiel ...

Die Kacke mit dem mehrfachen Insert wäre auch nciht am dampfen mit de IP-Sperre.

Aber wahrscheinlich ist deine Lösung die bessere *nachgeb* und anspruchsvollere , wobei ich das mit der IP nicht als "ganz schlechte Idee" abtun mag

cu

alligator

[lapso]

Original geschrieben von alligator

Naja das mit dem "Jetzt hab ich dich" waren zwei verschieden Ansatzpunkte ...

Genau, die nämlich gar nicht passten, aber Tingeltangelbobundso.

Aber mit deiner ID musst du doch ein Cookie setzen (oder zumindest sowas in der Art, weis ja nicht wie es in ASP ist)? Und schon brumst du deinem User/Surfer auf, dass er die aktiviert haben muss, da es sonst nicht geht, Und schon kommt der Faktor Sicherheit ins Spiel ...

Du musst gar keine SessionID setzen, weder als Cookie noch als Querystring. Du setzt in das Formular ein ID-Feld, mehr nicht.

BTW halte ich Cookies nicht wirklich für ein Sicherheits- sondern für ein Privatssphärenproblem, aber das is nu watt anneres.

Und Ja, bei classic-ASP bestehen die hauseigenen Sessions aus Cookies und sind auch aus weiteren Gründen nicht sonderlich empfehlenswert; da hat MS keine Hochglanzleistung vollbracht. Hab allerdings deswegen (und wegen Nokia-Handies, die kennen Cookies nicht...kroppzeuchsdas) eine eigene kleine cookielose Session gebastelt und die funzt wunderbar. Bei ASP.NET ist das sicherlich alles etwas moderner geworden *abschweif*

Die Kacke mit dem mehrfachen Insert wäre auch nicht am dampfen mit de IP-Sperre.

Ja, aber dann wäre eben ein anderer Stuhl am dampfen, und das wollten wir doch verhindern -- siehe letzte postings.

Aber wahrscheinlich ist deine Lösung die bessere *nachgeb* und anspruchsvollere , wobei ich das mit der IP nicht als "ganz schlechte Idee" abtun mag

Jaha, gib mir die genugttung ;)

Letzlich ist die IP-Sperre auf 10 Minuten für eine private Nippesseite kein Vergehen sondern eine simple und effektive Maßnahme. Das muss man eben abwägen.

solong, bin gerade zu einer Runde HL-DM aufgefordert worden.

Grüße

Matze

[Impulz]

Ich schliesse mich mal der Meinung an, dass eine IP Sperre mit zu den schlechtesten Loesungen gehoert bei Seiten mit einer hoeheren anzahl an views, vorallem wegen Proxies und NAT.

Meiner Meinung nach ist die beste Moeglichkeit um niemanden faelschlicherweise auszuschliessen ueber eine entsprechende Session und sog. Challenges.

Beispiel: http://jan.kneschke.de/projects/phpstate/

Original geschrieben von lapso

Oh, das würde ich nicht behaupten. Auf jeden Fall sollte man es wohl nicht in PHP/mySQL machen, das ist wohl wahr

auf die erklaerung bin ich ja mal gespannt..

[lapso]

Original geschrieben von Impulz

auf die erklaerung bin ich ja mal gespannt..

War nur ein Hieb gegen die "ASP-Ist-Zu-Lahm"-Fraktion. Eben keinen Deut besser als eben jene.

Andererseits - mySQL nehme ich nicht wirklich ernst. Dann müßte ich ja auch noch über Access nachdenken.

Gruesse

Matze

[Impulz]

Naja,

mysql mag nicht an der performance spitze liegen, aber fuer viele Projekte mag dies durchaus voellig ausreichen. Ich denke es hat seinen Grund dass mysql so weit verbreitet ist, insbesondere in verbindung mit php.

Und der Vergleich mit Access.. erm.. lassen wir das

Just my 0,02 €

[lapso]

Original geschrieben von Impulz

Naja,

mysql mag nicht an der performance spitze liegen, aber fuer viele Projekte mag dies durchaus voellig ausreichen. Ich denke es hat seinen Grund dass mysql so weit verbreitet ist, insbesondere in verbindung mit php.

Und der Vergleich mit Access.. erm.. lassen wir das

Just my 0,02 €

Naja, Access 2000 ist ja schon was ganz anderes als die vorigen Versionen. Ohne genaueres zu wissen kann es nur deutlich besser geworden sein mit der neuen Engine. Allerdings: Es gibt viele kleinere ASP-Webseiten, die ihre Daten aus einer alten Access holen.

mySQLs Verbeitung hat sicherlich gute Gründe (u.a. Lizensierung und Kosten). Der Funktionsumfang reicht wohl für eine Website mit Forum und Gästebuch. Transaktionen und Stored Procedures braucht man dazu wohl nicht zwingend. Oder hohe Perfomance bei etwas umständlicheren Abfragen.

Gruss

Matze

[lapso]

Original geschrieben von Impulz

Naja,

mysql mag nicht an der performance spitze liegen, aber fuer viele Projekte mag dies durchaus voellig ausreichen. Ich denke es hat seinen Grund dass mysql so weit verbreitet ist, insbesondere in verbindung mit php.

Und der Vergleich mit Access.. erm.. lassen wir das

Just my 0,02 €

aaalso, nochmal ein Nachschlag. Dass ich das nicht mit PHP machen würde liegt auch ganz einfach daran, dass ich in ASP sehr fortgeschritten bin und von PHP noch keinen blassen habe.

Was mir aber gerade in den letzten 5 Minuten (!) Surferei auffiel, waren gleich drei PHP/mySQL-Seiten (von drei). Und auf allen dreien(!!) habe ich mySQL und PHP-Fehlermeldungen gesehen, und das nicht nur einmal pro Seite.

Beispiele:

http://www.bbinternet.f2s.com/show_news.php?id=3

http://jan.kneschke.de/projects/phpgift/index.php?type=0&query=a

(URLS evtl. umgebrochen!)

<läster>Es hilft ja alles nix, wenn man nicht programmieren kann.</läster>

Grüße

Matze

[Impulz]

Hmpf

also zumindest jan kneschke kann sehr gut programmieren (nicht nur php). aber das phpgift scheint ne verbindung zu nem remote server aufbaun zu wollen, welcher aber das nit zulaesst, daher kein php/mysql fehler.

und bei f2s.com.. naja.. wer sich zu fein is 7dm/mon auszugeben fuer ordentlichen webspace is selbst schuld

Michael

[lapso]

Original geschrieben von Impulz

Hmpf

also zumindest jan kneschke kann sehr gut programmieren (nicht nur php). aber das phpgift scheint ne verbindung zu nem remote server aufbaun zu wollen, welcher aber das nit zulaesst, daher kein php/mysql fehler.

Michael

Hab ja nichts gegen den Herrn sagen wollen.

So, muss mich jetzt mal wieder mehr um die eine ASP-Seite hier kümmern.

Grüße

Matze