Director 7: Jetzt GET die POST ab ! (11/1998, Dir 7)

In diesem Bereich befinden sich Artikel und Tutorials zum Thema Director.

Moderatoren: Bär, Admin

Antworten
Admin
Site Admin
Beiträge: 41344
Registriert: 07.02.2006, 2006 16:09
Wohnort: München
Kontaktdaten:

Director 7: Jetzt GET die POST ab ! (11/1998, Dir 7)

Beitrag von Admin » 12.02.2006, 2006 19:34

Herzlichen Glückwunsch !

Unser geliebter Director ist nun endlich 7 geworden und gibt uns Anlaß ein paar Anmerkungen über die neuen Features zu machen.

Klar, das freie Rotieren, Skalieren, Spiegeln etc. von Text und Bitmap Darstellern, komplett mit Alpha-Kanälen, die Erstellung und totale Kontrolle von Vektorgraphiken via Lingo, die Einbindung von JPEG's und animierten GIF's, sowie die Farbkontrolle über RGB-Farben sind alles Dinge über die allein man schon ein ganzes Buch schreiben könnte. Jedoch sind es oft die unscheinbaren Feinheiten, die das Entwicklerherz höher schlagen lassen.

Anscheinend gibt es jemanden bei Macromedia, der die "Wish-List" wirklich liest, denn die von vielen Entwicklern lang ersehnte Funktion "postNetText", als Erweiterung zur "getNetText" Funktion ist nun endlich integriert. Wer schon einmal mit Shockwave gearbeitet und mit Hilfe eines Perl Skripts Daten auf dem Server gespeichert hat kennt die Problematiken der "getNetText" Funktion.

Zur Erklärung:

Server Requests können mittels zwei verschiedener Methoden "GET" und "POST" ausgeführt werden.

"GET"
Die GET-Methode übergibt dem Server die Argumente bzw. Parameter als Teil der URL, anstatt als eigenständige Daten. Dadurch kann nur eine limitierte Anzahl von Zeichen, entsprechend der maximalen URL-Länge übertragen werden (je nach Browser).

"POST"
Die POST-Methode übergibt dem Server alle Information erst nach dem Senden der URL. In anderen Worten, nachdem der Server die URL bekommen hat, wartet er auf die Argumente bzw. den Rest der Information. Diese Methode erlaubt eine theoretisch unbegrenzte Anzahl von Zeichen bei der Übermittlung der Daten.


Ein Beispiel

Das Problem:
Nehmen wir das klassische Beispiel des Shockwave-Spiels, welche mittels eines einfachen Perl Skriptes eine Highscore Tabelle speichert. Das Spiel ist so konzipiert, daß der Spieler am Ende seinen Namen in ein Feld einträgt und das Shockwave diesen zusammen mit seinem Punktestand an das CGI übergibt.

Wir benutzen die GET Methode um die Daten an das CGI zu übergeben:

Syntax: getNetText (URL)

Code: Alles auswählen

on submitHighscore
  global gScore, gNetID
  put the text of field "playerName" into myName
  put  "http://www.myserver.de/cgi-bin/highscore.cgi?score="& gScore & "&player=" & myName into highscoreString
  set gNetID = getNetText(highscoreString)
end
 
on exitFrame
  global gNetID
  if netDone(gNetID) then
    put the netTextResult (gNetID)
  else
    go the frame
  end if
end
Eine weitere Problematik ist die Formatierung des Strings. Meist haben wir es mit einem Unix-System zu tun und müssen daher Linefeeds, Leerzeichen, Umlaute und andere Sonderzeichen etc. erst "url-encoden" damit das CGI auch die richtigen Zeichen bekommt - ein Leerzeichen im String muß durch ein "+" ersetzt werden usw.
Also schreiben wir unseren eigenen Url-Encoder. Etwas umständlich, aber schnell gemacht und schreiben den String entsprechend unix-gerecht um. Nun zieht der Kunde aber samt Spiel und CGI auf einen NT-Server und von da nach 2 Monaten auf einen Apple-Server.
Was nun !?

Desweiteren bemerken wir, daß irgend jemand das Spiel verdammt gut spielt, denn er ist stets auf dem ersten Platz und erreicht unglaubliche Punktestände. Leider hat er sich nicht die Mühe gemacht das Spiel wirklich zu spielen, sondern lediglich den Server Request nachgemacht. Da die Daten bei der "GET" Methode an die URL angehängt werden, sind
sie auch im Browser, sprich in der Status- und Locationanzeige zu sehen.

Der Schummler kann einfach den Aufruf:

Code: Alles auswählen

http://www.myserver.de/cgi-bin/highscore.cgi?score=500000&player=god
direkt im Browser eingeben und schon ist er der Spielegott !

Dies ist gefährlich und beim Kunden sehr unbeliebt, besonders wenn es sich um Gewinnspiele handelt....

Die Lösung:
Die "POST" Methode schränkt dieses Risiko entscheidend ein. Da die Daten nicht über die URL selbst übermittelt werden kann diese zunächst nicht nachvollzogen werden.
Zwar gibt es Tricks, und um sicherzugehen sollten die Daten am besten nach einem bestimmten Verfahren verschlüsselt werden bevor sie übergeben und gespeichert werden, denn obwohl bei der Übermittlung nicht viel schief gehen kann, so kann doch eine einfache Textdatei auf dem Server schnell gesucht und eingesehen werden.

Kommen wir zurück zu unserem Beispiel und wenden wir die neue POST Methode an:

Code: Alles auswählen

Syntax:		postNetText(URL, postText [,serverOSString] [,serverCharSetString])
Hier sehen wir schon, daß die URL von den eigentlichen Daten (postText) getrennt wird.

Der optionale serverOSString Parameter gibt das Betriebssystem des Servers an, was zur Folge hat, daß Linefeeds entsprechend konvertiert werden um die Formatierung der Daten zu erhalten.

Der optionale serverCharSetString Paramter bestimmt das jeweiligen "Character-Set" auf dem Server. Damit lassen sich z.B. Sonderzeichen automatisch auf das jeweiligen "Character-Set" des Servers mappen.

Formate:
postText: ist ein String oder eine Eigenschaftsliste. Im Falle einer Eigenschaftliste wird diese wie bei HTML-Formen automatisch url-encoded gesendet !!!
serverOSString: Verwendet als Default "Unix", kann aber auch auf "Win" oder "Mac" gesetzt werden.
serverCharSetString: Mögliche Character-Sets sind: "JIS", "EUC", "ASCII"

Auf unser Beispiel übertragen, sieht es nun folgendermaßen aus:

Code: Alles auswählen

on submitHighscore
  global gScore, gNetID
  put the text of field "playerName" into myName
  set highscoreList = [ #player: myName, #score: gScore]
  set gNetID = postNetText("http://www.myserver.de/cgi-bin/highscore.cgi", highscoreList, "Unix", "ASCII")
end

Fazit:

Alles ist aufgeräumter, übersichtlicher und vor allem sicherer. Wer möchte schon kilometerlange Strings bilden indem eine Variable an die andere gehängt wird. Wieviel einfacher ist eine Eigenschaftsliste, besonders wenn es z.B. um ganze Adresseinträge geht.

Die Überprüfung im Frame-Loop (netDone) und das Resultat (netTextResult) funktionieren genau wie bei der "getNetText" Funktion. Wir fassen also zusammen:

Die kleine und unscheinbare "postNetText" Funktion sichert uns

- eine sichere Übertragung der Daten (nicht in Location- / Statusbar)
- eine bequeme Übertragung der Daten mittels einer Eigenschaftsliste
- eine zeitsparende Übertragung der Daten mittels der automatischen Url-Encodierung der Daten (nur bei Eigenschaftslisten)
- eine server-gerechte Übertragung der Daten über Angabe von Betriebssystem- und Character-Set Parameter

Nun kann eigentlich nichts mehr schiefgehen bei der Übertragung unserer Daten.

Autor: Martin Kloss

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste