2 Fragen zu Insert und $_SERVER['SCRIPT_NAME']

[Andy89]

Guten Tag,

bisher sah mein Form so aus auch in einer Session
<form  name="form" method="post" action="<?php echo $_SERVER['PHP_SELF'];?>">
nun lernte ich hier das ich dies nicht so schreiben soll wegen der Sicherheit nun tippe ich es so
<form  name="form" method="post" action="<?php echo $_SERVER['SCRIPT_NAME'];?>?SID=<?php echo $sid ;?>">

Meine Frage, warum muss ich hier die Session ID anhängen und bei PHP_SELF nicht?

ALs nächstes, auch wieder wegen der Sicherheit sieht mein insert nicht mehr so aus
 mysql_query("insert into ma
 ( manr , anmeldung  , lastlogin  , email  )
VALUES (
'".$inma."', '".$inanmeldung."',   sysdate(),   '".$inemail."'  )");

sondern so
$query1=sprintf("INSERT INTO ma SET
manr   = '%s',
.....
....
....
mysql_real_escape_string($_POST['inma']),
mysql_real_escape_string($_POST['inanmeldung']),
 sysdate(),
mysql_real_escape_string($_POST['inemail']),

ich habe jetzt ein Problem mit dem Sysdate, wie muss ich das in diesem Fall schreiben?

Besten Dank

[suit]

Meine Frage, warum muss ich hier die Session ID anhängen und bei PHP_SELF nicht?

Was hat die Session ID mit PHP_SELF zu tun - Doku gelesen, was PHP_SELF tut?
Du bekommst hier lediglich den Dateipfad des aktuellen Scripts relativ zum Wurzelverzeichnis - es wird weder der Hostname vorne noch der Querystring hinten angehängt

im übrigen ist es schlauer, die Session als Session-Cookie zu übergeben, dann hast du nicht überall diesen hässlichen string in deinen Pfaden - nur wenn Cookies nicht akzeptiert werden, solltest du die Anhäng-Variante nehmen.

ich habe jetzt ein Problem mit dem Sysdate, wie muss ich das in diesem Fall schreiben?

was ist sysdate()?
wenn du ein datum in eine datenbank schreiben willst, mach das entweder mit time() als unsigned int als unix timestamp oder nutze bei einer mysqldatenbank den datentyp timestamp (!= unix timestamp) bzw date_time und lasse diesen DIREKT von der datenbank setzen (default wert)

[Vinzenz Mai]

Hallo

ich habe jetzt ein Problem mit dem Sysdate, wie muss ich das in diesem Fall schreiben?
was ist sysdate()?

das hättest Du besser nachgesehen, bevor Du schlechte Ratschläge gibst ...
Es ist in diesem Zusammenhang klar, dass es sich um eine MySQL-Funktion handeln muss.

wenn du ein datum in eine datenbank schreiben willst, mach das entweder mit time() als unsigned int als unix timestamp

Nein! Nein!! Nein!!!

Das ist eine ganz schlechte, fürchterlich schlechte Idee. Auf solche Ideen kommen hauptsächlich PHP-Programmierer, die keine Ahnung von Datenbanken haben. :-( Nein, man nutzt für Datums- und Zeitangaben den angemessenen Datentyp des Datenbankmanagementsystems - ganz genauso wie es der OP ohnehin schon macht.

oder nutze bei einer mysqldatenbank den datentyp timestamp (!= unix timestamp)

Nur wenn man den Zauber des TIMESTAMP-Datentyps benötigt.

bzw date_time

Der Datentyp heißt DATETIME.

und lasse diesen DIREKT von der datenbank setzen (default wert)

Allmählich werden die Ratschläge besser und läuft auf das hinaus, was der OP ohnehin schon macht :-) Siehe SYSDATE().

Freundliche Grüße

Vinzenz

[suit]

wenn du ein datum in eine datenbank schreiben willst, mach das entweder mit time() als unsigned int als unix timestamp

Nein! Nein!! Nein!!!

Das ist eine ganz schlechte, fürchterlich schlechte Idee. Auf solche Ideen kommen hauptsächlich PHP-Programmierer, die keine Ahnung von Datenbanken haben. :-( Nein, man nutzt für Datums- und Zeitangaben den angemessenen Datentyp des Datenbankmanagementsystems - ganz genauso wie es der OP ohnehin schon macht.

nicht zwingend, es gibt durchaus anwendungsfälle in denen es schlauer ist, einen unix timestamp zu verwenden - und das machen auch php entwickler die ahnung von dem haben, was sie tun

man verschiebt ansich nur die zeitformatierung von der datenbank nach zur scriptsprache

Der Datentyp heißt DATETIME.

ertappt - der mysql datentyp heissts natürlich DATETIME

[ChrisB]

Hi,

nicht zwingend, es gibt durchaus anwendungsfälle in denen es schlauer ist, einen unix timestamp zu verwenden - und das machen auch php entwickler die ahnung von dem haben, was sie tun

man verschiebt ansich nur die zeitformatierung von der datenbank nach zur scriptsprache

Nein, man "verschiebt" viel mehr - unter anderem die Moeglichkeit, schon bei der Selektion komfortabel und guenstig Datumsberechnungen vornehmen zu koennen.

MfG ChrisB

[Tom]

Hello,

nicht zwingend, es gibt durchaus anwendungsfälle in denen es schlauer ist, einen unix timestamp zu verwenden - und das machen auch php entwickler die ahnung von dem haben, was sie tun

man verschiebt ansich nur die zeitformatierung von der datenbank nach zur scriptsprache

Nein, man "verschiebt" viel mehr - unter anderem die Moeglichkeit, schon bei der Selektion komfortabel und guenstig Datumsberechnungen vornehmen zu koennen.

Wenn man genau darüber nachdenkt, dann schränkt man nur den Wertebereich ein.
Denn ein "normaler" Unix-Timestamp läuft nur vom

Thu, 01.01.1970 01:00:00
bis zum
    Tue, 19.01.2038 04:14:07

und der Date-Bereich von MySQL reicht von

1000-01-01           1000-01_01 00:00:00
bis
    9999-12-31           9999-12-31 23:59:59

Aus einem Unix-Timestamp kann man aber jederzeit ein Datum in der obigen Darstellung wieder erzeugen. Die Datumsfunktionen stehen dadurch alle zur Verfügung.
Aus einem Datum der obigen Darstellung kann man aber nicht jederzeit einen Unix-Timestamp machen!

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de

[suit]

Wenn man genau darüber nachdenkt, dann schränkt man nur den Wertebereich ein.

datetime benötigt zur speicherung der daten 8 bytes wärend timestamp nur 4 benötigt, der vergleich hier hinkt etwas

---
es gibt durchaus gründe, warum man php time() dem datentyp timestamp vorziehen sollte - stichwort schaltsekunden, in der unix zeit werden diese ignoriert, mysql rechnet diese mit

die int-form der datenspeicherung wird nicht nur von ahnungslosen php programmierern verwendet - TYPO3 speichert zb zeitpunkte als integer, auch mediawiki tut das (allerdings nicht nur, einige tabelle nutzen int, andere timestamp als datentyp)

[Tom]

Hello,

datetime benötigt zur speicherung der daten 8 bytes wärend timestamp nur 4 benötigt, der vergleich hier hinkt etwas

Das ist wirklich grausam, was da an Speicherplatz verballert wird.
Da uss ich wirklich eine nutzlose, weil leere, Low-Level-Datei von meinem System verbannen, um 2000 Datensätze mehr statt mit Unix_Timespamp mit DateTime-Format abspeichern zu können.

Angesichts dessen, dass ein Bild für meine kleine Zeitung unbearbietet schon mindestens 1.400.000 Bytes hat, könnte ich stattdessen sogar 350.000 Datensätze mehr mit einigermaßen anständigem Zeitformat speichern, wenn ich endlich mal EIN EINZIGES von den ca. 4.000 unbrauchbaren löschen würde.

Aber das macht ja Mühe. Da spare ich lieber am Format für den Zeitstempel.

*rarara*

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de
.

[suit]

datetime benötigt zur speicherung der daten 8 bytes wärend timestamp nur 4 benötigt, der vergleich hier hinkt etwas
*rarara*

ich weiss nicht ob ich dir jetzt folgen kann, sprich ob aus dir sarkasmus spricht oder ob das ernsthaft gemeint war

es macht durchaus sinn, den richten datentyp zu wählen - auch wenn man dadurch nur 4 bytes spart

angenommen man erzeugt eine rainbow table mit md5 hashes

als datentyp char/varchar benötigt man 32 bytes zur speicherung eines hashes, da es sich aber nur um eine 128-bit zahl handelt, ist ads ziemlich verschwenderisch - das ganze binär zu speichern spart also 50% platz (16 bit)

ob meine tabelle jetzt 20 oder 40 GB belegt ist dann schon wieder von belang

natürlich fällt es bei einem redaktionssystem mit 1000 news nicht ins gewicht ob ich 4 bytes mehr pro eintrag brauche - aber es gibt andere begrenzungen

ein datensatz darf in mysql im tabellentyp myisam nur 2^16 bytes gross sein - da sind 4 bytes augenscheinlich auch nicht viel, aber 50% ersparnis bei einem feld ist eine große sache

eine myisam tabelle darf übrigens auch nur 2 bis 4 gb gross sein, wenn man ein altes dateiystem verwendet

[Tom]

Hello,

Du bekommst hier lediglich den Dateipfad des aktuellen Scripts relativ zum Wurzelverzeichnis - es wird weder der Hostname vorne noch der Querystring hinten angehängt

zuzüglich der "Path Info", also einer Ergänzug, die man hionter einer gültigen URL noch anhängen kann.

http://example.org/startseite.php/hier/steht/eventuell/noch/was

Aufgerufen wird nun vom Apache mit nicht ausgeschaltetem Path-Info-Feature die Ressource startseite.php auf der Domain und dieser werden noch die Anhänge übergeben.
Diese landen dann in $_SERVER['PATH_INFO'], das aber nur vorhanden ist, wenn es solche Anhänge gibt.

Sie landen aber auich in $_SERVER['PHP_SELF'] und das ermöglicht die Entführung von Formularen.
Man muss z.B. einem Opfer nur einen Link auf seine "Loginseite" mit entsprechendenm Anhang senden, er bekommt das Originalformular vorgelegt, das jetzt aber ein manipuliertes action-Attribut enthält.

Das Login landet dann also z.B. beim Linkversender.

Ein harzliches Glückauf

Tom vom Berg

http://bergpost.annerschbarrich.de

[Vinzenz Mai]

Hallo Andy,

ALs nächstes, auch wieder wegen der Sicherheit sieht mein insert nicht mehr so aus
mysql_query("insert into ma
( manr , anmeldung  , lastlogin  , email  )
VALUES (
'".$inma."', '".$inanmeldung."',   sysdate(),   '".$inemail."'  )");

ob Du VALUES mit Spalten- und Wertliste oder SET mit einzelnen Zuweisungen benutzt, hat keinen Einfluss auf die Sicherheit.

sondern so
$query1=sprintf("INSERT INTO ma SET
manr   = '%s',
.....

lastlogin = SYSDATE(), -- das ist für PHP eine einfache Zeichenkette,
                       -- diese muss nicht behandelt und nicht
                       -- übergeben werden.

....
....
mysql_real_escape_string($_POST['inma']),
mysql_real_escape_string($_POST['inanmeldung']),
mysql_real_escape_string($_POST['inemail']),

Freundliche Grüße

Vinzenz

[Andy89]

Hallo Vinzenz,

ob Du VALUES mit Spalten- und Wertliste oder SET mit einzelnen Zuweisungen benutzt, hat keinen Einfluss auf die Sicherheit.

aber das mysql_real_escape_string($_POST['xyz']), ?

ansonsten Danke ich Dir vielmals für die Erklärung und Hilfe, ich habe es verstanden!

Da ich nicht so viel in PHP erstelle, komme ich manchmal mit den verschiedenen Schreibweisen nicht klar.

eigentlich wollte ich mir die oben aufgeführte angewöhnen, doch leider lande ich sehr oft bei der althergebrachten.
wie hier
   mysql_query("insert into tab(f1,f2) values (
    '".mysql_real_escape_string($_POST['f1'])."',
    '".mysql_real_escape_string($code)."')");
          }

Ein schönes Wochenende
Andy

[Auge]

Hallo

ob Du VALUES mit Spalten- und Wertliste oder SET mit einzelnen Zuweisungen benutzt, hat keinen Einfluss auf die Sicherheit.

aber das mysql_real_escape_string($_POST['xyz']), ?

Ja, _das_ hat erheblichen Einfluss auf die Sicherheit.

Da ich nicht so viel in PHP erstelle, komme ich manchmal mit den verschiedenen Schreibweisen nicht klar.

eigentlich wollte ich mir die oben aufgeführte angewöhnen, doch leider lande ich sehr oft bei der althergebrachten.
wie hier
   mysql_query("insert into tab(f1,f2) values (
    '".mysql_real_escape_string($_POST['f1'])."',
    '".mysql_real_escape_string($code)."')");

Das ist ja auch die Notation, die man normalerweise in Büchern oder auf Websites bei den Beispielen und Tutorials findet. Die andere Notation (mit SET) finde ich mittererweile besser, da sie der gleichen Logik wie UPDATE folgt, man sich somit nur noch eine Syntax für den täglichen Gebrauch merken muss.

Tschö, Auge