Re(5): Web -> Input Element (CSS FF vs IE)

Impressum | Werbung

Geizhals » Forum » Programmierung »

Web -> Input Element (CSS FF vs IE) (12 Beiträge, 218 Mal gelesen)

Top-100 | Fresh-100

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi!

Firefox:

IE9

CSS:
input.text {
  width:300px;
  border:1px solid;
  padding: 0px 3px;
  margin: 3px 10px;
}

HTML:
<table>
<tr>
<td><label>Firma: </label></td>
<td><input type="text" name="firma" class="text" maxlength="<?php echo $zeichenlaenge_firma; ?>" value="<?php echo $_POST[firma]; ?>" /></td>
<td></td>
</tr>

Ich komm leider nicht drauf, wieso der Firefox Version 21 Probleme macht

Könnt ihr mir helfen

?

Danke
Frankster

Re: Web -> Input Element (CSS FF vs IE) (Frankster am 28.06.2013, 20:06:01)

Re: Web -> Input Element (CSS FF vs IE) (hellbringer am 29.06.2013, 08:27:43)

Re(2): Web -> Input Element (CSS FF vs IE) (ZombyKillah am 01.07.2013, 21:45:15)

Re(3): Web -> Input Element (CSS FF vs IE) (hellbringer am 01.07.2013, 22:04:59)

Re(4): Web -> Input Element (CSS FF vs IE) (Frankster am 01.07.2013, 22:55:06)

Re(4): Web -> Input Element (CSS FF vs IE) (ZombyKillah am 01.07.2013, 23:25:09)

Vor der Übergabe an die Datenbank muss man den Übergebenen Text ohnehin
analysieren oder umwandeln, da man sonst eine SQL-Injektion riskiert

Analysieren, ja. Umwandeln, nein.

da man sonst eine SQL-Injektion riskiert

Wenn man Prepared Statements verwendet, sind SQL-Injections unmöglich.

warum den Text also nicht gleich so abspeichern wie man Ihn nachher ausgeben
will.

Weil es falsch ist. Die Umwandlung findet beim Kontextwechsel statt. Was machst du, wenn du die Daten einmal nicht in einer HTML-Seite, sondern zB. in einem PDF- oder Excel-Dokument ausgeben möchtest? Dann hast du den ganzen HTML-Müll in der Datenbank stehen und musst ihn dann wieder vorher rausfiltern. Außerdem verhinderst du so effektiv, dass die Datenbank richtig sortieren, filtern und indexieren kann. Es bringt nur Probleme und keine Vorteile.

Außerdem ersparst du dir die Maskierung beim Kontextwechsel sowieso nicht, da du ja nicht davon ausgehen kannst, dass alle Daten immer aus der Datenbank kommen. Schlussendlich hast du dann ein Mischmasch aus nichtmaskieren, richtig maskierten und doppelt maskierten Daten. Na herzlichen Glückwunsch.

Es ist weit sinnvoller die Umwandlung bei der Eingabe zu machen ... weniger
Code und weniger Rechenleistung von Nöten.

Der Code wird nicht mehr. Zumindest nicht, wenn man sauber nach dem DRY-Prinzip programmiert. Wenn man Copy&Paste-mäßig programmiert, dann ist der erzeugte Code natürlich Müll und schwer wartbar.

Und wenn du dir bei sowas wegen der Rechenleistung sorgen machst, darfst du gar kein PHP verwenden. Denn PHP an sich verschwendet mindestens das tausendfache der Leistung, die du damit einsparen willst. Dafür gibts übrigens auch ein Stichwort: Mikrooptimierung.

Du solltest das optimieren, was wirklich viel Rechenleistung frisst, und nicht den kleinen Fliegenschiss.

Dafür braucht man halt 0,1-1% mehr speicher ... bei manchen Sonderzeichen eben
3 byte statt 1 byte.

Zu heutigen Zeiten, wo ein Server mehrere GB RAM und hunderte/tausende GB an Festplattenspeicher hat, bedeutungslos. Das soll ja kein Programm für einen C64er werden. Und wenn doch, dann ist PHP die falsche Sprache bzw. MySQL der falsche Datenspeicher.

Voraussetzung: Method = GET!

Nein, auch POST!

Sobald man POST verwendet, müsste man die übergebenen Variablen erst in einen
Skipt initialisieren => XSS Angriff führt sich ab-absurdum, da Skript bereits
unbemerkt ausgeführt wird.
Ist aber ausführbar.

Geht das auch in Deutsch? Ich versteh nicht, worauf du hinaus willst.

01.07.2013, 23:39 Uhr - Editiert von hellbringer, alte Version: hier

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung