Marco1174 Geschrieben 21. Dezember 2001 Geschrieben 21. Dezember 2001 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 Zitieren
Impulz Geschrieben 30. Dezember 2001 Geschrieben 30. Dezember 2001 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 Zitieren
alligator Geschrieben 30. Dezember 2001 Geschrieben 30. Dezember 2001 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 Zitieren
Buhu Geschrieben 30. Dezember 2001 Geschrieben 30. Dezember 2001 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 Zitieren
DanielH Geschrieben 2. Januar 2002 Geschrieben 2. Januar 2002 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 Zitieren
lapso Geschrieben 2. Januar 2002 Geschrieben 2. Januar 2002 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 Zitieren
alligator Geschrieben 2. Januar 2002 Geschrieben 2. Januar 2002 Hi. @lapso Hmm jetzt bin ich aber mal gespannt mit welcher erklärung? cu alligator Zitieren
lapso Geschrieben 2. Januar 2002 Geschrieben 2. Januar 2002 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 Zitieren
alligator Geschrieben 2. Januar 2002 Geschrieben 2. Januar 2002 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 Zitieren
lapso Geschrieben 2. Januar 2002 Geschrieben 2. Januar 2002 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 Zitieren
alligator Geschrieben 2. Januar 2002 Geschrieben 2. Januar 2002 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 Zitieren
lapso Geschrieben 2. Januar 2002 Geschrieben 2. Januar 2002 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 Zitieren
alligator Geschrieben 2. Januar 2002 Geschrieben 2. Januar 2002 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 Zitieren
lapso Geschrieben 2. Januar 2002 Geschrieben 2. Januar 2002 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 Zitieren
Impulz Geschrieben 4. Januar 2002 Geschrieben 4. Januar 2002 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.. Zitieren
lapso Geschrieben 4. Januar 2002 Geschrieben 4. Januar 2002 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 Zitieren
Impulz Geschrieben 4. Januar 2002 Geschrieben 4. Januar 2002 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 € Zitieren
lapso Geschrieben 4. Januar 2002 Geschrieben 4. Januar 2002 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 Zitieren
lapso Geschrieben 4. Januar 2002 Geschrieben 4. Januar 2002 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 Zitieren
Impulz Geschrieben 4. Januar 2002 Geschrieben 4. Januar 2002 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 Zitieren
lapso Geschrieben 4. Januar 2002 Geschrieben 4. Januar 2002 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 Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.