/ MySQL - Gästebuch: Verbesserungsmöglichkeiten + Sicherheit

[Fabian St.]

Hi!

Ich habe seit einiger Zeit an einem auf PHP und MySQL basierenden Gästebuch gearbeitet. Nun ist es soweit fertig, dass ich es online stellen könnte. Da ich mir jedoch nicht ganz sicher bin, ob ich nicht doch eine Lücke übersehen habe, die dazu verwendet werden könnte, eigenen Code einzuschleusen, will ich doch erst mal die Experten einen Blick darüber werfen lassen.
Natürlich würde ich mich auch freuen, wenn auch jemand Anmerkungen zum Code hat, d.h. ob es vielleicht nicht doch eine Möglichkeit gibt, eine bestimmte Funktion einfacher zu gestalten, etc.

Um den Einstieg zu erleichtern, hier eine kleine Übersicht zu den Dateien:

add.php --> Seite, an die das Formular geschickt wird + Ausgabe
            eventl. Fehler (Email ungültig etc.)
connect.inc.php --> Funktionssammlung für Verbindung zur DB etc.
functions.inc.php --> alle Funktionen
index.php --> Startseite des Gästebuchs mit Ausgabe aller Einträge +
              Formular zum Eintragen

Darüber hinaus sind alle Dateien auch einigermaßen gut dokumentiert.

Hier der Link zu den Skript (einfach auf die Dateien klicken, werden dann "gehighlighted" angezeigt):

http://fabis-site.net/src/

Grüße,
Fabian St.

[Andreas Lindig]

Hallo,

http://fabis-site.net/src/

schön ordentlich vorbereitet. Hast Du denn auch einen Link zum testen?

Gruß, Andreas

[Fabian St.]

Hi Andreas!

http://fabis-site.net/src/

schön ordentlich vorbereitet. Hast Du denn auch einen Link zum testen?

Ja, hätte ich, wobei der aber im Moment noch durch eine .htaccess geschützt ist. Ich wollte ihn erst posten, wenn sich das ganze ein paar angeschaut haben - nicht dass dann wer (nicht du, ich weiß ;-)) meine Datenbank zuspammt. Darüber hinaus habe ich gerade auch mein Gentoo abgeschossen, sodass ich mir erstmal unter SuSE einen FTP-Client einrichten muss.

Grüße,
Fabian St.

[Andreas Lindig]

nicht dass dann wer (nicht du, ich weiß ;-)) meine Datenbank zuspammt.

das kann man doch wieder löschen :-)

Gruß, Andreas

[Fabian St.]

Hi!

das kann man doch wieder löschen :-)

Hast ja recht :-) Hier der Link: http://fabis-site.net/tmp/

Grüße,
Fabian St.

[wahsaga]

hi,

was als erstes auffällt, ist dein vorgehen zum "absichern" der daten beim eintragen in die DB.
gut, dass du dir überhaupt gedanken gemacht hast, aber m.E. nicht ganz in die richtige richtung.

stripslashes wendest du auf die übergebenen daten an, wenn nötig - gut.

aber vor dem eintragen in die DB solltest du die daten mit mysql_escape_string() oder mysql_real_escape_string() absichern, _nicht_ mit addslashes. das läuft zwar in den allermeisten fällen auf das selbe hinaus - aber die mysql_escape_string-funktionen sind extra dafür gedacht, die daten für mysql-queries abzusichern, also sollten sie an der stelle auch genutzt werden.

und bei der ausgabe benutzt du dann wiederum deine stripslashes-funktion - das ist aber an der stelle vermutlich sogar eher hinderlich.
das maskieren erfolgt ausschließlich zur korrekten übergabe an die datenbank-_schnittstelle_. in den daten in der datenbank selber sind dann eventuell zu maskierungszwecken hinzugefügte \ schon gar nicht mehr vorhanden - es besteht also keine notwendigkeit, beim auslesen und ausgeben nochmals die slashes zu strippen [1] - im gegenteil, es kann sogar eher kontraproduktiv sein, weil dann ein vom benutzer gewollte eingegebenes \ dadurch entfernt wird, und in der ausgabe _ganz fehlt_.

gruß,
wahsaga

[1] es sei denn, magic_quotes_runtime wäre aktiviert, dann würden aus der DB ausgelesene daten ggf. auch noch mal ge"slasht". aber default für diese einstellung ist off.
wenn man's ganz genau nehmen und portabel halten will, wäre hier ggf. noch mal eine prüfung analog zu get_magic_quotes_gpc angesagt.

[Fabian St.]

Hi!

aber vor dem eintragen in die DB solltest du die daten mit mysql_escape_string() oder mysql_real_escape_string() absichern, _nicht_ mit addslashes. das läuft zwar in den allermeisten fällen auf das selbe hinaus - aber die mysql_escape_string-funktionen sind extra dafür gedacht, die daten für mysql-queries abzusichern, also sollten sie an der stelle auch genutzt werden.

Also sollte z.B. der SQL-Query zum Eintragen so ausschauen, oder?

INSERT
                  INTO guestbook
                         (name, email, zeit, homepage, nachricht, ip)
                  VALUES
                         ('".mysql_escape_string(htmlentities($name))."',
                          '".mysql_escape_string(htmlentities($email))."',
                          NOW(),
                          '".mysql_escape_string($www)."',
                          '".mysql_escape_string(htmlentities($message))."',
                          '".$ip."'
                         );";

und bei der ausgabe benutzt du dann wiederum deine stripslashes-funktion - das ist aber an der stelle vermutlich sogar eher hinderlich.
das maskieren erfolgt ausschließlich zur korrekten übergabe an die datenbank-_schnittstelle_. in den daten in der datenbank selber sind dann eventuell zu maskierungszwecken hinzugefügte \ schon gar nicht mehr vorhanden - es besteht also keine notwendigkeit, beim auslesen und ausgeben nochmals die slashes zu strippen [1] - im gegenteil, es kann sogar eher kontraproduktiv sein, weil dann ein vom benutzer gewollte eingegebenes \ dadurch entfernt wird, und in der ausgabe _ganz fehlt_.

Oh, Danke! Disen Punkt habe ich z.B. erst gar nicht bedacht. Wie gesagt, wenn ich wieder ein funktionierendes System habe, werde ich die Seiten aktualisieren.

Grüße,
Fabian St.

[wahsaga]

hi,

Also sollte z.B. der SQL-Query zum Eintragen so ausschauen, oder?
[...]
                  VALUES
                         ('".mysql_escape_string(htmlentities($name))."',

nicht ganz.
htmlentities würde ich eher bei der ausgabe der daten anwenden - denn zum sicheren eintragen in die DB ist es nicht relevant, ob umlaute etc. durch ihre HTML-entitäten ersetzt werden.
um die sicherheit der abfrage kümmert sich mysql_(real_)escape_string() schon vollkommen ausreichend.

htmlentities würde ich eher bei der ausgabe der daten als HTML anwenden - denn diese ist ja auch die relevante stelle.

natürlich könnte man darüber philosophieren, dass man so diese funktion bei _jeder_ ausgabe anwenden muss, während man sie nur _ein mal_ anwenden muss, wenn man die daten schon so in die DB einfügt.

aber von der performance her sollte das in einem system von "normaler" nutzung wie einem gästebuch nicht relevant sein.
und zum anderen lassen sich die daten besser editieren, wenn du sie noch in dem format vorliegen hast, in dem sie auch eingegeben wurden.
darüber hinaus weißt du ja u.U. jetzt noch gar nicht, ob du die daten nicht eventuell irgendwann mal in einem anderen format als HTML ausgeben möchtest - da wären entities dann vermutlich eher störend.

gruß,
wahsaga

[Fabian St.]

Hi wahsaga!

nicht ganz.
htmlentities würde ich eher bei der ausgabe der daten anwenden - denn zum sicheren eintragen in die DB ist es nicht relevant, ob umlaute etc. durch ihre HTML-entitäten ersetzt werden.
um die sicherheit der abfrage kümmert sich mysql_(real_)escape_string() schon vollkommen ausreichend.

OK, das habe ich nun soweit gehend abgeändert.

htmlentities würde ich eher bei der ausgabe der daten als HTML anwenden - denn diese ist ja auch die relevante stelle.

Sollte ich htmlentities auf alle Felder anwenden, also sowohl auf Name, Email, Homepage, Nachricht? Der Grund hierfür liegt darin, dass ich nicht genau weiß, was mit Domains passiert, die einen Umlaut enthielten (ist ja jetzt möglich), wenn diese Umlaute durch ä und Konsorten ersetzt werden. Könne diese dann immer noch erreicht werden?

aber von der performance her sollte das in einem system von "normaler" nutzung wie einem gästebuch nicht relevant sein.
und zum anderen lassen sich die daten besser editieren, wenn du sie noch in dem format vorliegen hast, in dem sie auch eingegeben wurden.
darüber hinaus weißt du ja u.U. jetzt noch gar nicht, ob du die daten nicht eventuell irgendwann mal in einem anderen format als HTML ausgeben möchtest - da wären entities dann vermutlich eher störend.

Das war mitunter für mich auch ein Grund, warum ich htmlentities() schon beim Eintragen der Daten in die Datenbank verwendete, aber wenn du meinst, dass es keinen Vorteil bringt, dann will ich das mal so glauben.

Grüße,
Fabian St.

[TomIRL]

Hallo Ihr beiden,
Als Quintessens und fürs Archiv schlage ich folgende Funktion zum sicheren maskieren beim eintragen in die Datenbank vor:

function encodeText($_str=0) {
  $_str = strip_tags($_str);       // Entferntag alle PHP und HTML Tags
  $_str = htmlentities($_str);   //  Wandelt alle Sonderzeichen in HTML
  $_str = mysql_escape_string ($_str); // Maskiert gebliebenen OR u.s.w.
  return($_str);
  }

Beim auslesen muß der String dann nur noch mit stripslashes () behandelt werden.

Stimmt Ihr mit mir überein?
Oder sollten wir was verbessern?

TomIRL

[Fabian St.]

Hi TomIRL!

function encodeText($_str=0) {
  $_str = strip_tags($_str);       // Entferntag alle PHP und HTML Tags
  $_str = htmlentities($_str);   //  Wandelt alle Sonderzeichen in HTML
  $_str = mysql_escape_string ($_str); // Maskiert gebliebenen OR u.s.w.
  return($_str);
  }

Beim auslesen muß der String dann nur noch mit stripslashes () behandelt werden.

Stimmt Ihr mit mir überein?
Oder sollten wir was verbessern?

IMHO stellt die Funktion - wie ich dir auch schon per Mail schrieb - eine gute Lösung des Problems dar, wobei natürlich wiederum die Frage geklärt werden sollte, ob htmlentities() schon vor dem Eintragen verwendet werden sollte oder erst bei der Ausgabe, s.a. https://forum.selfhtml.org/?t=93921&m=567935

Grüße,
Fabian St.

[TomIRL]

Hi Fabian,

IMHO stellt die Funktion - wie ich dir auch schon per Mail schrieb - eine gute Lösung des Problems dar, wobei natürlich wiederum die Frage geklärt werden sollte, ob htmlentities() schon vor dem Eintragen verwendet werden sollte oder erst bei der Ausgabe, s.a. https://forum.selfhtml.org/?t=93921&m=567935

Ich denke für die Anwendung "Gästebuch" ist es relativ egal.

Wichtiger wäre die Frage sauber zu programmieren und Coderedundanzen zu vermeiden zu klären.
Aus dieser Sicht wäre eine Trennung in 2 Funktionen sinvoll.
Die 2. Funktion könnte nämlich auch bei der Ausgabe von Formulardaten ganz nüztzlich sein.
Das komplette Paket würde dann so aussehen, Außerdem hätte man so die Chance je nach Anwendung einfach den Strings noch eine andere  Behandlung zu verpassen.
function encodeText($_str=0) {
$_str = strip_tags($_str);       // Entferntag alle PHP und HTML Tags
$_str = mysql_escape_string ($_str); // Maskiert gebliebenen OR u.s.w.
return($_str);
}

function decodeText($_str=0) {
$_str = htmlentities($_str);   //  Wandelt alle Sonderzeichen in HTML
$_str = sripslashes($_str); Entfernt die Formulardaten
return($_str);
}

[Andreas Lindig]

wobei natürlich wiederum die Frage geklärt werden sollte, ob htmlentities() schon vor dem Eintragen verwendet werden sollte

Ich habe das anfangs bei meinem Forum so gemacht und bin da in Teufels Küche gekommen mit dem ewigen hin und her konvertieren. (Vorschau, Änderungen, unterschiedliche Zeichensätze...)

Jetzt speichere ich alles genau so, wie es eingegeben wurde, bzw. in dem entsprechenden Zeichensatz. Dann habe ich eine Referenzstelle, an der ich immer 'nachsehen' kann, was gemeint war und und von da aus Umwandlungen vornehemen.

Gruß, Andreas

[TomIRL]

Jetzt speichere ich alles genau so, wie es eingegeben wurde, bzw. in dem entsprechenden Zeichensatz. Dann habe ich eine Referenzstelle, an der ich immer 'nachsehen' kann, was gemeint war und und von da aus Umwandlungen vornehemen.

D.h. Du behandelst die Daten erst bei der Ausgabe?
Das würde ich aus Sicherheitsgründen nicht tun.

TomIRL

[Johannes Zeller]

Hallo Tom,

Jetzt speichere ich alles genau so, wie es eingegeben wurde, bzw. in dem entsprechenden Zeichensatz. Dann habe ich eine Referenzstelle, an der ich immer 'nachsehen' kann, was gemeint war und und von da aus Umwandlungen vornehemen.

D.h. Du behandelst die Daten erst bei der Ausgabe?
Das würde ich aus Sicherheitsgründen nicht tun.

Sag mir mal bitte, wo du bei dieser Vorgehensweise ein Sicherheits-Problem siehst.

Schöne Grüße,

Johannes

[TomIRL]

Hallo Johannes,

Sag mir mal bitte, wo du bei dieser Vorgehensweise ein Sicherheits-Problem siehst.

Ein Problem besteht in sogenannten sql injections:
 http://www.php-faq.de/q/q-sql-injection.html

TomIRL

[wahsaga]

hi,

Sag mir mal bitte, wo du bei dieser Vorgehensweise ein Sicherheits-Problem siehst.

Ein Problem besteht in sogenannten sql injections:
http://www.php-faq.de/q/q-sql-injection.html

die fängt mysql_(real_)escape_string() m.E. aber in ausreichendem maße ab.
das man diese _funktion_ vor dem einsetzen der daten in die query anwendet, darüber waren wir uns hier ja eigentlich einig ;-)

aber andere sachen wie htmlentities() o.ä. betreffen wirklich nur die ausgabe (und auch nur, wenn diese als HTML geschieht), sind als an der stelle "eintragen in dei DB" m.E. nicht relevant in punkto sicherheit.

gruß,
wahsaga

[Fabian St.]

Hi!

Ich habe das anfangs bei meinem Forum so gemacht und bin da in Teufels Küche gekommen mit dem ewigen hin und her konvertieren. (Vorschau, Änderungen, unterschiedliche Zeichensätze...)

Na dann werde ich mal die jetzige Methode beibehalte, d.h. dass ich htmlentities() erst bei der Ausgabe anwende. Wird wohl das beste sein.

Bezüglich des Spam-Schutzes (dein Post im Gästebuch):

Die Spamsperre funktioniert, wie du in functions.inc.php sehen kannst, mit Hilfe der IP. Ich habe hier zum Testen mal die Zeit nach der man gesperrrt ist, auf 1min gesetzt. Nachher ändere ich das auf min. 60min. Es kann also einfach sein, dass du für deine Beiträge jeweils einfach länger als 1min gebraucht hast.
Ich weiß, dass dies keine sehr zuverlässige Methode ist, da dadurch u.U. auch welche ausgesperrt werden, z.B. die hinter einem Proxy sitzen und ihre IP mit jemanden teilen. Aber eine absolut sichere Methode gibt es ja wohl nicht.

[s.a. [http://fabis-site.net/tmp/index.php]

Grüße,
Fabian St.

[Fabian St.]

Hi!

[s.a. [http://fabis-site.net/tmp/index.php]

Sorry, ich mein http://fabis-site.net/tmp/index.php natürlich ;-)

Grüße,
Fabian St.

[Fabian St.]

Hi Andreas!

Ich hätte da noch eine Frage:

Du warst ja wahrscheinlich der mit dem laaaaaaaaaaaannnngen Wort, oder ;-)

Wie könnte ich das denn vermeiden?

Grüße,
Fabian St.

[Andreas Görtz]

Hi Fabian,

Du warst ja wahrscheinlich der mit dem laaaaaaaaaaaannnngen Wort, oder ;-)

Wie könnte ich das denn vermeiden?

wordwrap()  kann Wörter mit einer bestimmten Anzahl von Zeichen trennen:

$newstr = wordwrap($str, 50, ' ', 1);

z.B. würde alle Wörter, die länger als 50 Zeichen sind, mit Leerzeichen trennen. Diese Lösung enthält bestimmt einige Nachteile, aber vielleicht reicht es dir ja?!

Gruß,
Andreas.

[Fabian St.]

Hi Andreas!

wordwrap()  kann Wörter mit einer bestimmten Anzahl von Zeichen trennen:

$newstr = wordwrap($str, 50, ' ', 1);

z.B. würde alle Wörter, die länger als 50 Zeichen sind, mit Leerzeichen trennen. Diese Lösung enthält bestimmt einige Nachteile, aber vielleicht reicht es dir ja?!

Ja, das schaut ganz gut aus. Werde versuchen die heute Nachmittag noch einzubauen. Vielen Dank!

Grüße,
Fabian St.

[Andreas Lindig]

Ich hab mir eine Funktion gebastelt, die einen eingigermaßen gleichmäßigen Umbruch auch über viele Zeilen macht und das Wort zuerst an seinen eigenen Bindestrichen teilt - und das auch möglichst gleichmäßig verteilt.

Ich hab da jetzt einiges rausgelöscht, was Du nicht brauchst (schützen bestimmter Syntaxen vor Umbruch), weiß deshalb nicht genau, ob es die Funktion so jetzt tut:

//$text = zu editirender String
   //$untergrenze = mindestwortläng
   //$obergrenze = max. Wortlänge
   //man stellt also einen unscharfen Bereich ein, in dem Umbrochen wird
   //so kann man einen gleichmäßigen Block erreichen
   function umbruch($text, $untergrenze, $obergrenze)
   {

/*** Nur die einzelnen zu langen Woerter mit Wordwrap behandeln ***/
      // 1. Gesamttext in Zeilen aufteilen
      $zeilen = preg_split ("|\n|", $text);
      foreach($zeilen as $key_z=>$zeile)
      {
         // 2. Zeilen in woerter aufteilen
         $woerter = preg_split ("| |", $zeile);
         foreach($woerter as $key_w=>$wort)
         {
            $laenge = strlen($wort);

//gleichmäßige Teilung errechnen, wenn Obergrenze um 2 Zeichen ueberschritten wird (Trennzeichen: -_)
            if($laenge > ($obergrenze + 2))
            {
               //wieviele Teile ergeben sich bei Teilung?
               $oberanzahl = floor($laenge/$obergrenze);
               //welcher Relst bleibt?
               $oberrest = $laenge%$obergrenze;

if($oberrest)
               {
                  $unterlaenge = floor($laenge/($oberanzahl + 1));
                  $unterrest = $laenge%$unterlaenge;
                  $add = ceil($unterrest/($oberanzahl + 1));

$teilung = $unterlaenge + $add;
               }
               else
                  $teilung = $obergrenze;

//erst an 'natürlichen' Bindestrichen teilen...
               $bindestrichteilung = preg_replace("/(.{".round($teilung * 0.7).",".$teilung."})-/U", "$1- ", $wort);
               //dann die sich ergebenden Teile nochmals teilen, falls noetig
               if($bindestrichteilung)
               {
                  $teilwoerter = explode(' ', $bindestrichteilung);
                  #echo join('<br>', $teilwoerter);
                  $woerter[$key_w] = '';
                  foreach($teilwoerter as $teilwort)
                     if( strlen($teilwort) >= ($teilung * (1/0.7)) )
                        $woerter[$key_w] .= wordwrap($teilwort, $teilung, "- ", 1).' ';
                     else
                        $woerter[$key_w] .= $teilwort.' ';
               }
               else
                  $woerter[$key_w] = wordwrap($wort, $teilung, "- ", 1);
            }
            else
               $woerter[$key_w] = $wort;

}
         $zeile = join(" ", $woerter);
         $zeilen[$key_z] = $zeile;
      }
      //4. Zeilen wieder zu Text zusammenfuegen
      $text = join("\n", $zeilen);

return $text;
   }

Gruß, Andreas

[Fabian St.]

Hi Andreas!

Ich hab mir eine Funktion gebastelt, die einen eingigermaßen gleichmäßigen Umbruch auch über viele Zeilen macht und das Wort zuerst an seinen eigenen Bindestrichen teilt - und das auch möglichst gleichmäßig verteilt.
[function umbruch()]

Vielen Dank :-) Die Funktion ist ja beinahe solange wie meine ganze Funktionen zusammen ;-) Ich bin mir daher nicht sicher, ob sie nicht doch zu umfangreich für dieses Projekt ist. Auf alle Fälle habe ich sie mir mal gebookmarkt!

Grüße,
Fabian St.

[wahsaga]

hi,

Beim auslesen muß der String dann nur noch mit stripslashes () behandelt werden.

na ja, nicht wirklich, siehe meine vorherige antwort. oder nur dann, wenn man sich vorher nicht um magic_quotes_gpc gekümmert hat ...

Stimmt Ihr mit mir überein?

strip_tags() mag ich eigentlich nicht besonders.

bei eingabe von
x ist < 4 und 5 > als y
bekomme ich nach behandlung mit strip_tags()
x ist als y
heraus.

einen vernünftigen grund, warum ich diese eingabe aus sicherheitsgründen nicht erlauben bzw. derart verfälschen sollte, kann ich aber nicht erkennen.

da beschränke ich mich lieber auf htmlentities(), dass mir dann auch wirklich diese eingabe, natürlich html-kodiert, zurückliefert.

wenn dann wirklich irgendjemand mit <script> o.ä. herumprobieren muss, dann erscheint das halt auch _sichtbar_ in der ausgabe. kann ich mit leben.

gruß,
wahsaga

[Andreas Lindig]

wenn dann wirklich irgendjemand mit <script> o.ä. herumprobieren muss, dann erscheint das halt auch _sichtbar_ in der ausgabe. kann ich mit leben.

nicht nur das: derjenige wird meist schnell aufgeben, wenn er seinen Schmarrn auch noch in der Ausgabe zu lesen bekommt :-)

Gruß, Andreas

[Fabian St.]

Hi!

Ich habe jetzt alle Punkte, auf die ich hingewiesen worden bin, versucht umzusetzen.
Hier der Link zum Ausprobieren: http://fabis-site.net/tmp/index.php

Sourcen: http://fabis-site.net/src/

Grüße,
Fabian St.

[Fabian St.]

Hi!

Ich habe nun abermals die überarbeitete Version online gestellt. Berichtigt habe ich den Umstand, dass die Eingabefelder für Name und Mail mehr Zeichen zu lassen, als nachher angezeigt werden. Außerdem habe ich die Funktion change_text() um wordwrap() ergänzt, damit lange Wörter nach 40 Zeichen abgeschnitten werden, sodass sie nicht mehr das Layout zerschießen.
Im Moment arbeite ich noch an einer Vorschau-Funktion, spätestens am Mi/Do wird das alte Gästebuch dann durch das neue ersetzt.

Grüße,
Fabian St.

[Tobias Kloth]

Hallo Fabian,

Ich habe nun abermals die überarbeitete Version online gestellt.

drei Sachen sind mir aufgefallen:
 - Warum muss der Name mindestens 5 Zeichen enthalten?
 - Wenn ich ein Euro-Zeichen eingebe, steht im Text dann nur &#8364;
 - Als Text solltest du nicht beliebig lange Texte zulassen, ich habe testweise mal 200kB Daten gepostet, das hat das Script angenommen (welchen Type hat die Spalte 'nachricht' eigentlich?)

Grüße aus Nürnberg
Tobias

[Fabian St.]

Hi Tobias!

• Warum muss der Name mindestens 5 Zeichen enthalten?

Wenn ich mir das jetzt nochmal überlege, hast du wohl recht - 5 Zeichen sind wahrscheinlich zuviel?! Immerhin kann ja jemand "Uli", "Jan" etc. heißen.

• Wenn ich ein Euro-Zeichen eingebe, steht im Text dann nur &#8364;

Danke für den Hinweiß! htmlentities() verwendet wohl den falschen Zeichensatz (ISO-8859-1). Darin ist das €-Zeichen nämlich nicht enthalten.

• Als Text solltest du nicht beliebig lange Texte zulassen, ich habe testweise mal 200kB Daten gepostet, das hat das Script angenommen (welchen Type hat die Spalte 'nachricht' eigentlich?)

Die Spalte 'nachricht' ist vom Typ TEXT. Sollte ich hierfür vielleicht einen anderen wählen?

Grüße,
Fabian St.

[Tobias Kloth]

Hallo Fabian,

Wenn ich mir das jetzt nochmal überlege, hast du wohl recht - 5 Zeichen sind wahrscheinlich zuviel?! Immerhin kann ja jemand "Uli", "Jan" etc. heißen.

eben. Auch at hätte ein Problem wenn er in dein Gästebuch schreiben wollte :-)

• Als Text solltest du nicht beliebig lange Texte zulassen, ich habe testweise mal 200kB Daten gepostet, das hat das Script angenommen (welchen Type hat die Spalte 'nachricht' eigentlich?)
  Die Spalte 'nachricht' ist vom Typ TEXT. Sollte ich hierfür vielleicht einen anderen wählen?

das nicht, aber ich würde die Anzahl der Zeichen die man Posten kann einschränken.

Grüße aus Nürnberg
Tobias

[Fabian St.]

Hi Tobias!

Wenn ich mir das jetzt nochmal überlege, hast du wohl recht - 5 Zeichen sind wahrscheinlich zuviel?! Immerhin kann ja jemand "Uli", "Jan" etc. heißen.
eben. Auch at hätte ein Problem wenn er in dein Gästebuch schreiben wollte :-)

Stimmt! Das muss dann natürlich umgehend geändert werden :-)

• Als Text solltest du nicht beliebig lange Texte zulassen, ich habe testweise mal 200kB Daten gepostet, das hat das Script angenommen (welchen Type hat die Spalte 'nachricht' eigentlich?)
  Die Spalte 'nachricht' ist vom Typ TEXT. Sollte ich hierfür vielleicht einen anderen wählen?
  das nicht, aber ich würde die Anzahl der Zeichen die man Posten kann einschränken.

Wieviel Zeichen sind deiner Meinung nach sinnvoll? Höchstens 1000?

Grüße,
Fabian St.