Ein paar Fragen zu PHP

[Lilly]

Hallo euch allen,

hmm ich weiß gar nicht wie ich anfangen soll. Ich muss für die Schule ein paar Vorteile und Nachteile aufschreiben warum es gut bzw. eben nicht gut ist dass man einen komplette Homepage in eine Seite schreiben soll.

Die Vorgabe lautet so:

Erkläre warum das http://www.eine_Seite.de/?show=index gut bzw. nicht gut ist.

Hmm ich habe schon mal was überlegt:

Vorteile:

Man auf in seinem Ordner also auf dem Server nicht so viele Dateien liegen.

Nachteile:

Wenn ein Skript mal abbricht dann steht alles still und es geht nichts mehr.

So das habe ich schon mal. Kennt Ihr noch mehr Sachen die dafür Sprechen bzw. dagegen?

Dann habe ich noch eine andere Frage:

Wenn man das so macht wie das oben geschrieben worden ist wo kommen dann die ganzen Skripte hin bis jetzt habe ich die immer nur wenn ich eine Seite habe ganz oben hin gemacht und habe eben dann bei Action gesagt die gleiche Seite. Aber wie muss das dann da lauten?

Ich hoffe mir kann hier jemand helfen!

Gruß Lilli

[Daniel]

Hi,

Erkläre warum das http://www.eine_Seite.de/?show=index gut bzw. nicht gut ist.

was auf jedenfall ein nachteil ist, das ganze läuft über $_GET und das kann man "faken" $_POST wäre besser.

MfG

PS: hab keine zeit für ne ausvürlichere antwort fals du dies willst. weil ich mach dann feierabend und fahr heim.

[xola]

Tach auch,

PS: hab keine zeit für ne ausvürlichere antwort fals du dies willst.

Darum sollte man googeln, um so etwas zu finden. Wenn du nichts findest (der zweite Punkt in der Auflistung bei Google sieht vielversprechend aus) dann kannst du hier fragen :)

That's it -
xola

[wahsaga]

hi,

Erkläre warum das http://www.eine_Seite.de/?show=index gut bzw. nicht gut ist.
was auf jedenfall ein nachteil ist, das ganze läuft über $_GET und das kann man "faken" $_POST wäre besser.

POST lässt sich genauso "faken".
aber was soll's - fehlerhafte eingaben abzufangen, ist aufgabe des programmierers.
z.b. könnte man prüfen, ob die angegebene "datei" lokal auf dem server vorhanden ist, oder ob sie in einer liste der erlaubten vorkommt.

"nicht gut" ist auf jeden fall, wenn der programmierer hier schlampt, und gar keine prüfung vornimmt; evtl. sogar noch _externe_ ressourcen auf diese weise eingebunden werden können.

so weit zum programmiertechnischen.

aus sicht der benutzerfreundlichkeit sind links á la script.php?seite=kontakt natürlich auch nicht die schönsten.

mod_rewrite o.ä. können hier zu "schöneren" URLs verhelfen.

gruß,
wahsaga

[Tom]

Hello,

[...] Ack

"nicht gut" ist auf jeden fall, wenn der programmierer hier schlampt, und gar keine prüfung vornimmt; evtl. sogar noch _externe_ ressourcen auf diese weise eingebunden werden können.

... und die dann ggf. auch noch mit include() eingebunden werden.
Dann sit der Server offen. Darum predige ich immer wieder, dass Anfänger erstmal mit Templates und str_replace() arbeiten sollten und nicht mit include()!

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ashura]

Hallo Tom.

Darum predige ich immer wieder, dass Anfänger erstmal mit Templates und str_replace() arbeiten sollten und nicht mit include()!

IMHO sollte man sich als Anfänger einfach etwas ausgebiger mit dem Kapitel Sicherheit befassen, was eigentlich bei nahezu jeder Programmiersprache, die erweiterte Dateizugriffe hat, enthalten ist.

Wenn dann verinnerlicht hat, welche Sicherheitsvorkehrungen getroffen werden müssen, um weitestgehend alles abfangen zu können, was Schaden anrichten könnte, kann man meiner Meinung nach auch gut und gerne include() verwenden.

(Ja, ich weiß, dass viele Anfänger einfach drauflosschreiben. ;) )

Gruß, Ashura

[Dennis]

Hi Daniel,

Erkläre warum das http://www.eine_Seite.de/?show=index gut bzw. nicht gut ist.
was auf jedenfall ein nachteil ist, das ganze läuft über $_GET und das kann man "faken" $_POST wäre besser.

$_GET['show'] scheint hier in einem Kontext genutzt zu werden, dass durch show übermittelt wird, welche Seite angezeigt wird - dann ist POST _definitiv nicht_ besser, da der User sich bei POST keine Seite mehr bookmarken könnte.

Unabhängig davon hat dir wahsaga ja schon gesagt, dass man $_POST Daten genauso "faken" kann.

Auch Argumente wie "Der User kann nicht sehen, was für Variablen übermittelt werden" gelten nicht, denn z.B. mit LiveHTTPHeaders für FF oder ein Blick in den Quellcode hilft da dem User sofort weiter.

Ein weiteres Sicherheitsrisiko besteht darin, wenn die index.php so aussieht:

include $_GET['show'];

Dann lässt sich jede beliebige Datei auf dem Server (auf die das Script Zugriff hat) anzeigen, auch ein . ".php" hinter $_GET hilft da nicht weiter.

MfG, Dennis.

[e7]

Hi,

dass man einen komplette Homepage in eine Seite schreiben soll.

Es gibt keine Vorteile, wenn man eine 5 MB-Datei hat, das braucht nur länger in PHP...

Erkläre warum das http://www.eine_Seite.de/?show=index gut bzw. nicht gut ist.

Allgemein würde ich sagen: Wenn man das intern mit include löst, und das Design sauber trennt (auch include oder so was), gibt es keine wirklichen Nachteile...

Und für alle, die ihre Seite auf Suchmaschinen optimieren wollen (Google indiziert normalerweise Seiten bis 1 Parameter, alles andere bleibt Pagerank-starken Seiten vorbehalten), gibt's mod_rewrite, um das auch noch zu verstecken... Aber eine Datei, die alles erledigt, eine (oder zwei (1x oben, 1x unten) oder so, oder drei mit CSS) für das Design und der Rest alles als PHP-Dokumente in einem Unterverzeichnis ist wohl das übersichtlichste, was man sich ohne weiteren Aufwand basteln kann...

Wenn ich 200 Dateien habe, in denen jeweils einmal eine oben.php und eine unten.php included wird, wird mir persönlich das zu kompliziert (im Vergleich zum include)...

E7

[Tom]

Hello Lilli,

Erkläre warum das http://www.eine_Seite.de/?show=index gut bzw. nicht gut ist.

da müsste man ein wenig in die Systemtechnik und die Sicherheitsfragen einsteigen, um das zu erklären. Es ist definitiv schlecht, es so zu machen. Es ist aber schon besser, als wenn man es

http://www.eine_Seite.de/?page=122
  http://www.eine_Seite.de/?page=123
  http://www.eine_Seite.de/?page=124
  http://www.eine_Seite.de/?page=125

so macht.

Was ist der Unterschied?

Es ist die Ordinalisierung des Seitenparameters bei gleichzeitiger Einschränkung des Wertevorrats.
Von 256 Zeichen (oder eben entsprechend URL-Konventionen ca. die Hälfte) reduziert man den Wertevorrat eines Digits auf 10 Zeichen. Damit wird eine so aufgebaute Webseite sehr leicht "grabbable", also die Daten in ihrer Gesamtheit leichter stehlbar. Wenn man den Wertevorrat pro digit erhöht, steigt die Gesamtmenge der möglichen Kombinationen exponentiell an.

Wenn man also nicht will, dass jemand sich einfach _alle_ Daten einverleibt, um sie widerrechtlich (aber das ist immer schwer beweisbar) zu verwenden, dann sollte man das nicht so (mit den Zahlen) machen.

Die Zahlen nhaben aber den Vorteil, dass man erlaubte und verbotene Zeichen sehr leicht voneinander unterscheiden kann.

Wenn man nun auf die Textvariante ausweicht, weil die ja einen größeren Wertevorrat hat, dann muss man sehr genau die Methode auswählen, mit der gearbeitet wird und die erlaubten und verbotenen Zeichen sehr genau auswählen muss. Anderenfalls wäre ggf. sowas möglich

http://www.eine_Seite.de/?index=%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f%2f%2fetc%2f/passwd%20#

und wenn die Aufruffunktion etwas ungeschickt geschreiben ist, wird plötzlich die Passwortdatei des Systems (die ja hoffentlich verschlüsselt oder mit * vershen ist) ausgeliefert. Das Beispiel hinkt natürlich, denn ich will hier keine Anleitungen geben, sondern nur die Möglichkeit aufzeigen.

Es wurde ja schon gesagt, dass der Mod_Rewrite das Mass der Dinge sein könnte.
Was macht den den sicherer?

Ganz einfach: Er benutzt das Pfadsteuerzeichen (Slash) als Parametertrenner und unterbindet dadurch, dass man von außen Pfade einschleppen kann. Außerdem erlaubt der den größtmöglichen Wertebereich, den so ein Paramterstring zulässt. Damit kann man Pfade zur Ressource nicht mehr so leicht erraten.

Den Mod_Rewrite kann man sich übrigens ganz leicht selber bauen.
Du musst nur Dein Error-Dokument auf eine Auswerte-Datei umbiegen und kannst in dieser dann den Paramterstring des Requests zerlgen und aus den einzelnen entstehenden Paramtern die ressource bestimmen, die ausgeliefert werden soll.

Vorteil der Methode allgemein gegenüber dem statischen Web ist die Vermeidung von Redundanzen. Man kan  _eine_ zentrale Funktion für die Berechnung dee Navigation aufbauen, man kann die Köpfe, Füße, Designs und auch aktuelle Nachrichten berechnet einblenden, ohn das auf jeder Seite einzeln programmieren zu müssen. Die Methode mit einer zentralen Index-Datei (oder wie die auch heißt) funktioniert also immer gut bei bestehnder Ploymorphie. Wenn alle Seiten gänlich unterschiedlich sind, sehe ich keinen Vorteil.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom