Server "vergißt" Formulardaten / Cookies

[reinhard]

Hallo Leute,
ich habe eine Anwendung mit Active Server Pages (ASP) programmiert, die serverseitig im IIS läuft. Dabei gibt es Webseiten, die Cookies und Formulardaten (method=post) an eine Seite mit serverseitigem Skript senden. Am Server werden Cookie-/Formularinhalte (z.B. ID von Datensätzen) abgefragt, in Variablen übergeben und in SQL-Statements eingebaut.
Normalerweise funktioniert alles problemlos, aber:
bei Schulungen kommt es vor, daß auf "Kommando" des Schulungsleiters 10 Teilnehmer gleichzeitig auf einen Knopf drücken und Daten zur gleichen Seite am Server senden wollen. Mehrere Teilnehmer können dann Fehlermeldungen erhalten, weil z.B. in SQL-Statements die IDs fehlen, d.h. in den entsprechenden Variablen ist nur ein Leerstring vorhanden.
Ich habe folgenden Verdacht:

• Möglichkeit A: der Server kommt mit den (fast) gleichzeitig eintreffenden Daten nicht klar und "vergißt" sie
• Möglichkeit B: da in den gleichzeitig eintreffenden Cookie-/Formulardaten die gleichen Feldbezeichnungen vorkommen, werden aus einfachen Variablen plötzlich Array-Variablen, d.h. meine Abfrage der Formulardaten (ohne Array-Index) liefert kein Ergebnis.
  Folgende Fragen an Euch:
• hat jemand diesen Fehler auch schon einmal gehabt?
• liege ich mit meinen Vermutungen richtig?
• gibt es ein Gegenmittel?
• wo kann ich mich informieren, wie gleichzeitig eintreffende Anforderungen an die gleiche Seite am Server abgearbeitet werden?
• kann es passieren, daß sich gleichzeitig eintreffende Formulardaten "mischen" oder wird erst eine Anforderung abgearbeitet, bevor die nächste Anforderung bearbeitet wird? (d.h. gibt es für gleichzeitig eintreffende Anforderungen an eine Seite eine "Warteschleife"?)

Vielen Dank im Voraus für Eure Hilfe
und schöne Grüße,
Reinhard

[Rouven]

Hello,

Ich habe folgenden Verdacht:

• Möglichkeit A: der Server kommt mit den (fast) gleichzeitig eintreffenden Daten nicht klar und "vergißt" sie

ähm, nein.

• Möglichkeit B: da in den gleichzeitig eintreffenden Cookie-/Formulardaten die gleichen Feldbezeichnungen vorkommen, werden aus einfachen Variablen plötzlich Array-Variablen, d.h. meine Abfrage der Formulardaten (ohne Array-Index) liefert kein Ergebnis.

ähm, und wieder nein.

• hat jemand diesen Fehler auch schon einmal gehabt?

vielleicht.

• liege ich mit meinen Vermutungen richtig?

nein.

• gibt es ein Gegenmittel?

ich würde mal schauen, wie es mit der Client-Konfiguration, Firewall etc aussieht. Ich halte es für nahezu ausgeschlossen, dass den Server hier irgend eine Schuld trifft. Cookies und Formulardaten liegen primär in der Verantwortung des Browsers und es dürfte einen IIS nicht gerade mit voller Breitseite treffen wenn 10 Leute gleichzeitig eine Anfrage stellen. Ich vermute eher, dass der Fehler anderswo liegt.

MfG
Rouven

[reinhard]

Danke für die schnelle Antwort. Das Ganze verwundert mich auch sehr. Vor allem, weil es am gleichen Client kein Problem gibt, sobald die Mausklicks zeitlich (einige Sekunden) auseinander liegen. Nur wenn an mehreren Rechnern das gleiche Formular in derselben Sekunde gespeichert wird, gibt es Probleme ...
Ich habe es im Übrigen auch noch nicht geschafft, den Fehler außerhalb von Schulungen zu reproduzieren, obwohl ich mit javascript versucht habe, das gleichzeitige Absenden zu simulieren.
Gruß, Reinhard

[Rouven]

Hello,

das einzige was mir einfiele: Schau mal auf dem Server in die Logfiles rein, vielleicht tauchen irgendwelche Fehler auf. Aber wie gesagt, ich halte es für nahezu ausgeschlossen, dass ein Skript normale angestoßen und abgearbeitet wird, die zugehörigen Request-Daten aber fehlen.

MfG
Rouven

[reinhard]

Danke, werde ich machen!
Gibt es irgendwo eine Info, wie gleichzeitig eintreffende Anforderungen am Server (hier IIS) abgearbeitet werden? Gibt es "Warteschleifen"?
Gruß, Reinhard

Hello,

das einzige was mir einfiele: Schau mal auf dem Server in die Logfiles rein, vielleicht tauchen irgendwelche Fehler auf. Aber wie gesagt, ich halte es für nahezu ausgeschlossen, dass ein Skript normale angestoßen und abgearbeitet wird, die zugehörigen Request-Daten aber fehlen.

MfG
Rouven

[wahsaga]

hi,

bei Schulungen kommt es vor, daß auf "Kommando" des Schulungsleiters 10 Teilnehmer gleichzeitig auf einen Knopf drücken und Daten zur gleichen Seite am Server senden wollen. Mehrere Teilnehmer können dann Fehlermeldungen erhalten, weil z.B. in SQL-Statements die IDs fehlen, d.h. in den entsprechenden Variablen ist nur ein Leerstring vorhanden.
Ich habe folgenden Verdacht:

• Möglichkeit A: der Server kommt mit den (fast) gleichzeitig eintreffenden Daten nicht klar und "vergißt" sie

Die Request sind und bleiben voneinander unabhängig.
Selbst wenn der Server nicht so viele Verbindungen gleichzeitig handeln könnte - dann würde sich einfach eine Verzögerung bei der Beantwortung einzelner ergeben, oder eben eine Abweisung einzelner Requests.

• Möglichkeit B: da in den gleichzeitig eintreffenden Cookie-/Formulardaten die gleichen Feldbezeichnungen vorkommen, werden aus einfachen Variablen plötzlich Array-Variablen, d.h. meine Abfrage der Formulardaten (ohne Array-Index) liefert kein Ergebnis.

Nee, das ist komplett undenkbar.
Es wird zwar meinetwegen alles "an eine Seite" gesendet - aber trotzdem erzeugt der Server mehrere Scriptinstanzen, eine für jeden Request.

• wo kann ich mich informieren, wie gleichzeitig eintreffende Anforderungen an die gleiche Seite am Server abgearbeitet werden?

Wie schon erwähnt wurde, die Logs des Servers sollten mal betrachtet werden.

• kann es passieren, daß sich gleichzeitig eintreffende Formulardaten "mischen"

Nein.

oder wird erst eine Anforderung abgearbeitet, bevor die nächste Anforderung bearbeitet wird?

Nicht unbedingt nacheinander, ggf. auch parallel.
Aber auf keinen Fall "vermischt".

gruß,
wahsaga

[reinhard]

Vielen Dank!

die verschiedenen Antworten bestätigen an sich das, was ich bislang auch über diese Dinge wußte (obwohl ich kein Profi bin). Ich werde auf jeden Fall in das Serverprotokoll schauen und dann doch mal sehen, ob irgendwoanders ein Fehler stecken könnte. Aber wie gesagt, bei einzelnen Mausklicks läuft alles (monatelang) reibungslos.

Zusatzfrage:
Kann es überhaupt Fälle geben, in denen ein ordnungsgemäß gesendetes Cookie oder die ordnungsgemäß gesendeten Formulardaten bei der Übermittlung verloren gehen können?
Wenn z.B. die Cookies grundsätzlich bei allen Seiten ordnungsgemäß übermittelt werden und nur hin und wieder eines verschwindet (leider ohne regelmäßiges Muster), können es eigentlich nicht die Einstellungen am Browser / an der lokalen Firewall sein.
Nebenbei: Proxyserver werden bei der Anwendung umgangen.

Schöne Grüße,
Reinhard

[agapanthus]

Moin.

in Variablen übergeben und in SQL-Statements eingebaut.

Wie viele DB-Connections sind denn gleichzeitig zulässig? Oder werden die Daten in _einem gemeinsamen_ File zwischengespeichert und alle fummeln gleichzeitig dran rum (Stichwort file locking)?

Gruß Frank

[reinhard]

Moin, moin,

es sind genügend DB-Connections vorhanden. Wenn dies nicht der Fall wäre, käme eine andere Fehlermeldung.
Bei mir tritt der Fehler auf, weil schon das SQL-Statement fehlerhaft ist. Beipiel:
Das Statement wird zusammengesetzt aus

• String1 = "SELECT * FROM Tabelle WHERE ID = "
• request.cookies("ID") enthält Zahl 4711
• String2 = " AND XYZ = 'abc'"
  Ergebnis von: String1 & request.cookies("ID") & String2
  Normalfall: "SELECT * FROM Tabelle WHERE ID = 4711 AND XYZ = 'abc'"
  Fehlerfall: "SELECT * FROM Tabelle WHERE ID = AND XYZ = 'abc'"
  Im Fehlerfall ist also das cookie ein Leerstring.
  Der Server meldet dann bei der Ausführung logischerweise einen Syntaxerror im SQL-Statement.

Schon mal so einen Fehler gehabt?
Gruß, Reinhard

Moin.

in Variablen übergeben und in SQL-Statements eingebaut.
Wie viele DB-Connections sind denn gleichzeitig zulässig? Oder werden die Daten in _einem gemeinsamen_ File zwischengespeichert und alle fummeln gleichzeitig dran rum (Stichwort file locking)?

Gruß Frank

[Sven Rautenberg (off site)]

Moin!

Ich habe folgenden Verdacht:

• Möglichkeit A: der Server kommt mit den (fast) gleichzeitig eintreffenden Daten nicht klar und "vergißt" sie
• Möglichkeit B: da in den gleichzeitig eintreffenden Cookie-/Formulardaten die gleichen Feldbezeichnungen vorkommen, werden aus einfachen Variablen plötzlich Array-Variablen, d.h. meine Abfrage der Formulardaten (ohne Array-Index) liefert kein Ergebnis.

Im Gegensatz zu allen anderen Antwortgebern hier stelle ich auch mal die Möglichkeit C zur Auswahl:

- Möglichkeit C: Dein Skript benutzt irgendeinen globale Variablenraum oder kommt sich sonst gegenseitig ins Gehege, so dass du dir selbst die Daten überschreibst bzw. löschst.

Angesichts deiner Äußerungen zu deinem Erfahrungsstand würde ich das absolut nicht ausschließen. Denn es ist extrem unwahrscheinlich, dass der IIS durch zehn nahezu gleichzeitige Requests irgendwas vergisst. Das wäre ein SO extremer Bug, dass er bestimmt schon lange bekannt wäre und gefixt worden wäre.

• hat jemand diesen Fehler auch schon einmal gehabt?

Nein.

• liege ich mit meinen Vermutungen richtig?

Siehe Möglichkeit C. Ohne dein Skript zu kennen kann man nur mit einiger Sicherheit sagen, dass dort das Problem liegt, aber nicht, wo.

• gibt es ein Gegenmittel?

Mit Sicherheit... :)

• wo kann ich mich informieren, wie gleichzeitig eintreffende Anforderungen an die gleiche Seite am Server abgearbeitet werden?

Jeder Request läuft erstmal in seinem eigenen abgeschotteten Raum unabhängig von allen anderen. Allerdings ergeben sich Schnittpunkte dort, wo absichtlich oder unabsichtlich Kontakt zu anderen Prozessen hergestellt wird: In der Datenbank, im Dateisystem, in Session-Variablen oder in Applikationsvariablen (wir sprechen hier von ASP).

• kann es passieren, daß sich gleichzeitig eintreffende Formulardaten "mischen" oder wird erst eine Anforderung abgearbeitet, bevor die nächste Anforderung bearbeitet wird? (d.h. gibt es für gleichzeitig eintreffende Anforderungen an eine Seite eine "Warteschleife"?)

Es wird nichts gemischt, außer du selbst mischst in deinem Skript.

- Sven Rautenberg

[reinhard]

Hmmmm ...
Deine Möglichkeit C ist nicht ganz auszuschließen ...
Allerdings mache ich bewußt einen großen Bogen um die Sessionvariablen und Applikationsvariablen von ASP (vor allem schreibend). Das Skript ist m.E. zu lang für dieses Forum, daher die folgenden Anmerkungen:

• ich benutze eigentlich nur die ASP-Objekte "response" und "request", insbesondere "request.cookies(...)", "request.form(...)", "request.querystring(...)". Alle Werte aus diesen Objekten werden immer lokalen Variablen im Skript zugewiesen und nie irgendwelchen Applikationsvariablen o.ä. Aber diese Objekte stehen zentral zur Verfügung und werden von allen Webseiten der Anwendung benutzt. Könnten sie sich womöglich überschreiben, wenn 2 requests gleichzeitig eintreffen? Dann wäre der IIS unschuldig, oder? Ich baue mein SQL-Statement aus Teilstrings zusammen, wovon ein Teilstring der Inhalt eines cookies (request.cookies("ID")) ist (siehe meine Antwort an "agapanthus").

• für die DB-Verbindung erzeuge ich die nötigen Objekte mit "Server.CreateObject('ADODB.Connection bzw. recorset')". Hier könnte natürlich ein Hund begraben sein, da ich hier tatsächlich am Server tätig werde. An der Fehlermeldung sehe ich aber, daß schon das SQL-Statement falsch ist (siehe meine Antwort an "agapanthus").

Danke erstmal für den Tip, werde Möglichkeit C weiter im Auge behalten.
Reinhard

[Rouven]

Hello,

• ich benutze eigentlich nur die ASP-Objekte "response" und "request", insbesondere "request.cookies(...)", "request.form(...)", "request.querystring(...)". Alle Werte aus diesen Objekten werden immer lokalen Variablen im Skript zugewiesen und nie irgendwelchen Applikationsvariablen o.ä. Aber diese Objekte stehen zentral zur Verfügung und werden von allen Webseiten der Anwendung benutzt. Ich baue mein SQL-Statement aus Teilstrings zusammen, wovon ein Teilstring der Inhalt eines cookies (request.cookies("ID")) ist (siehe meine Antwort an "agapanthus").

das wollte ich schon die ganze Zeit sagen, auch wenn es nichts zum Thema beiträgt: AUTSCH - <Sicherheitslücke size="Scheunentor" /> - mach dir über SQL-Injection Gedanken.

Könnten sie sich womöglich überschreiben, wenn 2 requests gleichzeitig eintreffen? Dann wäre der IIS unschuldig, oder?

Nein, denn dann wäre der IIS (bzw. sein ASP-Modul) doch schuldig - ist er nicht.

• für die DB-Verbindung erzeuge ich die nötigen Objekte mit "Server.CreateObject('ADODB.Connection bzw. recorset')". Hier könnte natürlich ein Hund begraben sein, da ich hier tatsächlich am Server tätig werde.

du bist nicht "am Server" tätig. Du forderst das Objekt Server auf, ein anderes Objekt zu erstellen. Das ist etwas anderes, zumal du NICHT mit GetObject o.ä. arbeitest. Zumal du schon Recht hast, der Inhalt deiner Connection ist bereits das falsche Query...

Danke erstmal für den Tip, werde Möglichkeit C weiter im Auge behalten.
Reinhard

...die Serverlogs nachschauen...
...und mal nachschauen, ob in eurem Schulungsnetz etwas merkwürdig ist, vielleicht filter da irgendeine Software Massenrequests?!...

MfG
Rouven

[reinhard]

Hello,
das wollte ich schon die ganze Zeit sagen, auch wenn es nichts zum Thema beiträgt: AUTSCH - <Sicherheitslücke size="Scheunentor" /> - mach dir über SQL-Injection Gedanken.

Danke für den Hinweis auf den sehr interessanten Link. Das Problem ist mir bekannt, deshalb habe ich eine (kleine) Sperre eingebaut in dem Sinn, daß clientseitig bestimmte verbotene Zeichen, u.a. die Zeichen "'", ";", "|" und "<" + ">" (nur in Kombination wg. HTML-Tags) aus allen Eingabestrings geworfen werden. OK, das erledigt eine clientseitige Javascript-Routine, die man sicher auch manipulieren kann. Die Anwendung läuft aber in einem geschützten Intranet, wobei ich nicht annehme, daß wir so findige Hacker in der Firma habe, die soetwas manipulieren können. Wäre jedenfalls sensationell.

Zu meinem anderen Problem:
Gestern mußte ich wieder eine Schulung überstehen, bei der ich wg. dieses @*/%"@§$-Fehlers sehr geschwitzt habe. Immerhin hat sich mein Verdacht jetzt auf eine bestimmte Datei konzentriert. Diese Datei habe ich mit Protokollzeilen gespickt, die - falls der Fehler wieder auftritt - in eine eigene Protokolldatei weggeschrieben werden.

Mal sehen, wie die nächste Schulung läuft. Ich bin froh, daß wir einigermaßen geduldige Anwender haben. Ob ich den Fehler doch noch finde ... ?
Gruß, Reinhard