Fremde Scripte laufen bei mir nicht, bei Euch ?

[Meike]

Hallo,
ich habe eine Seite gefunden mit einigen interessanten Anregungen.
Bei: http://simplecontent.net/phpsnippets

Leider funktionieren die Scriptr dort (die meissten zumindet),
bei mir aber nicht und ich komme einfach nicht dahinter, warum das
so ist. Wäre also nett wenn Ihr ein paar davon ausprobiert
und mir sagt ob Ihr die gleichen Problem habt, bzw. woran
es liegen könnte.

Funktionieren bei Ihm, bei mir nicht:

*die sourcecodes befinden sich auch auf den Seiten,
gehen aber designtechnisch ein wenig unter. s.o. rechts
------------------------------------
Beispiel_1
Beispiel_2

Funktionieren auch bei Ihm nicht.
-------------------------------
Schade warum nur?

vg.
Meike

[rob]

Hi!

Leider funktionieren die Scriptr dort (die meissten zumindet),
bei mir aber nicht

Was heißt das? Bekommst du Fehlermeldungen? Wenn ja, welche?

und ich komme einfach nicht dahinter, warum das
so ist.

Eventuell liegt es an deiner PHP-Konfiguration. Vielleicht werden andere Einstellungen in deiner php.ini benötigt.
Vielleicht handelt es sich aber auch um alte PHP3-Scripte, die auf einem PHP4- oder PHP5-Server nicht mehr funktionieren. Vielleicht sind es aber auch PHP5-Scripte, die auch einem PHP4-Server nicht laufen.
Es gibt zwar einige Option für die Rückswärtskompatibilität, aber da kann und will man nicht immer Rücksicht drauf nehmen.
Z.B. die Sache mit register_globals oder die alten $HTTP_*_VARS und dann kann man jetzt erst mit PHP5 objektorientiert arbeiten; ging zwar auch mit PHP4, aber da hat sich jetzt 'ne Menge geändert. Muß man jetzt aber hier nicht drauf eingehen...

Wäre also nett wenn Ihr ein paar davon ausprobiert
und mir sagt ob Ihr die gleichen Problem habt, bzw. woran
es liegen könnte.

Nö... Keine Lust, mir Scripte runterzuladen und zu installieren.
Poste lieber mal Fehlermeldungen. Dann wird man sicher erkennen können, warum das bei dir nicht läuft.

Übrigens sind doch bei den meisten Scripten, die man im Netz findet, Doku-Files mit dabei. Ich wette, in jedem Script-Archiv liegt auch mindestens ein Textfile, wo drin steht, welche Vorraussetzungen erfüllt werden müssen, wie man den Krams installiert, usw..

Schöner Gruß,
rob

[Meike]

Hallo Rob,

Nö... Keine Lust, mir Scripte runterzuladen und zu installieren.
Poste lieber mal Fehlermeldungen. Dann wird man sicher erkennen können, warum das bei dir nicht läuft.

Übrigens sind doch bei den meisten Scripten, die man im Netz findet, Doku-Files mit dabei. Ich wette, in jedem Script-Archiv liegt auch mindestens ein Textfile, wo drin steht, welche Vorraussetzungen erfüllt werden müssen, wie man den Krams installiert, usw..

Fehlermeldungen gibts keine.
Installieren usw... ?
Das sind alles kleine Snipets copy => use => trash

Aber wenn du dir nicht mal die Mühe machst die Links
anzuschauen, hättest du dir den Post hier auch ersparen
können. Die theoretischen Gründe sind mir nämlich auch klar.

[Tom]

Hello Meike,

bist Du noch wach?

Fehlermeldungen gibts keine.

Dafür kann man aber i.d.R. durch Konfiguration des Servers oder durch einfügen einer Zeile im Script sorgen

error_reporting(E_ALL);   ## nur zum Testen! Sonst über Konfiguratioen steuern.

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

Tom

[Meike]

Hallo Tom

bist Du noch wach?

Klar, genau wie du ;-)

error_reporting(E_ALL);   ## nur zum Testen! Sonst über Konfiguratioen steuern.

Och Liebschen, dat wees isch doch all ;-)

Ausser unwesentlichen notice ist da nichts bei.

vg.
Meike

[Tom]

Hello,

error_reporting(E_ALL);   ## nur zum Testen! Sonst über Konfiguratioen steuern.

Ausser unwesentlichen notice ist da nichts bei.

So unwesentlich sind die meistens gar nicht.
Man kann meistens recht viel daraus schließen, wenn schaut, was sie ausgelöst hat.

Warum ich Notices für die wichtigsten Fehlermeldungen halte, weißt Du?
Sie deuten oft auf nicht initialisierte Variablen hin. Wenn man dann genau hinschaut, sind das manchmal die schlimmsten Sicherheitslücken.

Bei den anderen Fehlern wird das Script abgewürgt, kann also keinen Schaden mehr anrichten. bei Notices läuft es trotzdem weiter.

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

Tom

[Meike]

Warum ich Notices für die wichtigsten Fehlermeldungen halte, weißt Du?
Sie deuten oft auf nicht initialisierte Variablen hin. Wenn man dann genau hinschaut, sind das manchmal die schlimmsten Sicherheitslücken.

Interessant, bin ja schon ziemlich sicherheitorientiert,
aber in dem Zusammenhang sehe ich jetzt nicht wie man das
ausnutzen sollte.

Ich deklariere auch oft variabeln ohne Inhalt, wie
könnte man da Schaden anrichten?

Aber mal was lustiges am Rande, habe heute eine Datei
includet und zum Test (nur zum Test) ein @ davorgesetzt.
Dabei ist mir aufgefallen, dass auf der inludeten Datei
keine Fehler auftauchten.

Also nicht wie angenommen, bloss Fehlerunterdrückung
falls die Includedatei nicht vorhanden ist, nein
im gesamten Scriptablauf, wusstest du das?

Ich sehe so viele scripte wo das @ bei include eingesetzt
wird, denke mal die meissten wissen es nicht,
so wie ich bis heute.

gruss
Meike

[Tom]

Hello,

Ich deklariere auch oft variabeln ohne Inhalt, wie
könnte man da Schaden anrichten?

Wenn Du sie in PHP (prozedural) deklariert hast, haben sie einen Inhalt.
Variablen ohne Inhalt gibt es eigentlich gar nicht.

Die Lücke steckt im berühmten "Register Globals = on".

Da kann man ja über die Parameterliste allerhand einschleppen.
Und wenn Du dann ungeschickt auf ein einen Wert prüfst, der im Script nicht initialisert war, dann gilt eben der eingeschleppte.

Aber mal was lustiges am Rande, habe heute eine Datei
includet und zum Test (nur zum Test) ein @ davorgesetzt.
Dabei ist mir aufgefallen, dass auf der inludeten Datei
keine Fehler auftauchten.

Also nicht wie angenommen, bloss Fehlerunterdrückung
falls die Includedatei nicht vorhanden ist, nein
im gesamten Scriptablauf, wusstest du das?

Interessant!
Muss ich doch meinen Testserver gleich nochmal anschmeißen!

Du meinst also, dass die Fehlermeldungen des gesamten Blockes unterdruckt werden, wenn man

@include(block.php);

schreibt?

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

Tom

[Meike]

Wenn Du sie in PHP (prozedural) deklariert hast, haben sie einen Inhalt.
Variablen ohne Inhalt gibt es eigentlich gar nicht.

Na ja, aber laut notice halt undefiniert.
globals ON gehört ja eh schon der Vergangenheit an.

Siehst du auch ein Sicherheitsproblem bei globals OFF
wenn Variabeln undefiniert sind?

Interessant!
Muss ich doch meinen Testserver gleich nochmal anschmeißen!

Du meinst also, dass die Fehlermeldungen des gesamten Blockes unterdruckt werden, wenn man

@include(block.php);

Ja, also habe eine normale PHP-Datei als Template mit
einem Div-bereich in dem die incl.  kommen.

Diese bestehen auch aus HTML und PHP.

So nun war mir aufgefallen das bei einem Fehler in
so einer Datei kein Fehler angezeigt wurde. Da hab ich es
mal wissen wollen und extra haufen weise fehler untergebracht,
zb. funktionen die es nicht gibt usw. also bsp.
 fzuggfg();

Dann erst habe ich gemerkt, dass es an dem @ in der Hauptdatei
liegen könnte, zuvor stundenlang google danach abgesucht.

Ja, da ich Fehlerunterdrückung normalerweise nicht praktiziere,
war ich über die Auswirkung verwundert, bin mal gespannt ob es bei dir auch so ist.

PHP Version 5.2.1

Gruss
Meike

[Tom]

Hello,

@include(block.php);

Ja, da ich Fehlerunterdrückung normalerweise nicht praktiziere,
war ich über die Auswirkung verwundert, bin mal gespannt ob es bei dir auch so ist.

PHP Version 5.2.1

bei mir im Moment PHP 4.3.8
Die neuere habe ich vorhin erstmal geschreddert, als ich was einbauen wollte :-(

Es verhält sich genauso.
Wahrscheinlich ist das sogar so designed, was aber hässlich ist.

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

Tom

[Tom]

Hello,

es gibt (gab?) noch so einen alten Fehler.
Da haben mich die PHP-Leute mal ziemlich abgekanzelt, als ich ihnen das (sogar auf ihren Wunsch) wunderbar aufbereitet habe...

Zusammenspiel der dio_* Funktionen und flock().

Sind ja im Prinzip zwei verschiedene Schuhe, aber für ein Dateisystem!

Wenn man mit

$lock_ok = flock(filename,LOCK_EX + LOCK_NB)

eine Dateisperre anfordert, dann rauscht das Script am Statement mit Rückmeldung false vorbei, wenn bereits eine Dateisperre eines anderen Prozesses über flock() besteht. das ist OK so, erwartet man ja auch.

Wenn man dieselbe Datei nun aber mit einer dio_Funktion öffnet und sperrt, dann wartet das Script trotz LOCK_NB solange, bis die DIO-Sperre wieder freigegeben wurde. das würde ich jetzt nicht so erwarten.

Das kann man nur ausprobieren, wenn man Linux-Volume entsprechend für DIO gemounted hat.

Es ist ein schwerer Design-Fehler.

Es würde mich interessieren, ob das in der neuesten 5er-Version nun endlich funktioniert.

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

Tom

[dedlfix]

echo $begrüßung;

Variablen ohne Inhalt gibt es eigentlich gar nicht.
Na ja, aber laut notice halt undefiniert.

Ja, in dem Fall, aber kannst du auch garantieren, dass das immer so ist? Wirklich immer?

Siehst du auch ein Sicherheitsproblem bei globals OFF wenn Variabeln undefiniert sind?

Derzeit ist mir keine Lücke bekannt, die auch bei ausgeschaltetem register_globals Variablen einschleppt. Es muss aber nicht unbedingt von außen kommen. Auch selbst verschuldete nicht beachtete Fehler können Folgen nach sich ziehen.

Beispiel:

$resultset = array();
while ($row = datenbankabfrage())
  $resultset[] = $row;

foreach($resultset as ...)
  ...

Wenn du nun die erste Zeile nicht notierst, und die Datenbankabfrage, die sonst immer ein Ergebnis brachte, diesmal einfach mal keins liefert, gibt es $resultset nicht. foreach reagiert darauf etwas heftiger als nur mit einer Notice.

Außerdem ist es durchaus menschlich, bei größer werdendem Code nicht zu bedenken, dass man einen Variablennamen bereits an anderer Stelle schon einmal verwendet hat, der nun auf einmal einen übrig gebliebenen Wert enthält. Und wie es der Zufall so will, merkt man das bei Testen seines Scripts nicht.

Meine Erfahrung lehrt mich einfach, auf explizite Initialisierung nicht zu verzichten.

echo "$verabschiedung $name";

[Tom]

Hello,

Meine Erfahrung lehrt mich einfach, auf explizite Initialisierung nicht zu verzichten.

... und meine, bezogen auf Dein Beispiel, selbt für den kleinsten abgrenzbaren Pups eine eigene Funktion zu schreiben. Das grenzt das Scope ab und verbessert schließlich auch den Kontrollfluss und die Übersichtlichkeit.

Ich bedaure es nur, dass PHP für die prozedurale Programmierung immer noch keine private Functions kennt, also Funktionen in Funktionen.

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

Tom

[Tom]

Hello,

Aber mal was lustiges am Rande, habe heute eine Datei
includet und zum Test (nur zum Test) ein @ davorgesetzt.
Dabei ist mir aufgefallen, dass auf der inludeten Datei
keine Fehler auftauchten.

Ui wie hässlich!

<?php   ### test1.inc.php ###

$_test1 = array();
echo $nichtvorhanden;    ### nirgendwo initialisiert
highlight_file(__FILE__);
readfile('blah.blu');    ### File ist nicht vorhanden!

?>

<?php      ### include_test.php ###

error_reporting(E_ALL);

echo "<p>Error Reporting ist ".error_reporting()."</p>\n";

$ok = @include ('test1.inc.php');

echo "Include von test1 ergab $ok <br />";

if (file_exists('testdir/test1.inc.php'))
{
  echo "Datei ist vorhanden<br />";
}

if (is_readable('testdir/test1.inc.php'))
{
  echo "Datei ist lesbar<br />";
}

if (is_executable('testdir/test1.inc.php'))
{
  echo "Datei ist ausführbar<br />";
}

?>

Wenn man nun include-Test.php aufruft, werden tatsächlich alle (erzeugten) Fehlermeldungen des includierten Blockes unterdrückt.

Noch nicht einmal, wenn ich zusätzlich

trigger_error('nun aber Fehlermeldung!',2);

in die test1.inc.php einfüge, passiert etwas...

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

Tom

[Meike]

Tja Tom,
man lernt nie aus, und das ist gut so ;-)
Sonst wär das leben ja langweilig.

Wenn man nun include-Test.php aufruft, werden tatsächlich alle (erzeugten) Fehlermeldungen des includierten Blockes unterdrückt.

Noch nicht einmal, wenn ich zusätzlich

trigger_error('nun aber Fehlermeldung!',2);

in die test1.inc.php einfüge, passiert etwas...

Faszinierend, oder?
Da werden einige nochmal über Ihre Arbeitsweise nachdenken,
wenn sie das hier lesen.

Gruss
( für so einen Dialog fehlt hier eigentlich so ein kleiner Mini Chat)
Meike

[Tom]

Hello,

man lernt nie aus, und das ist gut so ;-)
Sonst wär das leben ja langweilig.

Ist wirklich spannend, was man so nachts noch rausfindet, wenn man nicht schlafen kann.
Ich habe mich vorhin schon geweundert, was wir da wohl mal ausprobiert hatten. das Beispiel war (bis auf die künstlichen Fehler) nämlich alt.

Das muss mit diesem hässlichen Verhalten zu tun gehabt haben. Ich hatte es aber vollkommen vergessen.

In den UCNs steht:

arnold at bean-it dot nl
24-Feb-2006 02:15
Currently there is no clean way to check if a file can be included. Simply including a file which can't be opened causes a warning to be triggered. Suppressing include() with an @ (as often seen below) is not advisable, since parse errors won't be displayed, but will cause the script to die, causing a blank screen. (Happy debugging, hope you're using ZendStudio or some other debugger).

The best solution I've come up with is:
<?php
    if (($fp = @fopen($filename, 'r', 1)) and fclose($fp)) include $filename;
?>

I believe the functions file_exists(), filesize(), is_readable() and is_writable() should have an use_include_path just like fopen().
If you agree with this, please PLEASE VOTE on bug #6932 (http://bugs.php.net/bug.php?id=6932). This bug has been open for over 5 years. Apparently no one is willing to add this feature.

Faszinierend, oder?
Da werden einige nochmal über Ihre Arbeitsweise nachdenken,
wenn sie das hier lesen.

Meinst Du wirklich?

( für so einen Dialog fehlt hier eigentlich so ein kleiner Mini Chat)

Jein. Den mag ich sowieso nicht.

Mal sehen, was uns noch so einfällt.

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

Tom

[Krueger]

Hallo,

Beispiel_1

ich hab mir nur dieses Script angeguckt und da ist ein Fehler drin. Bei den anderen ist es vermutlich ebenso. Der Fehler liegt also beim Programmierer und nicht bei PHP.

Zeile 29. So ist es falsch und steht so im Quelltext:
$replacement = '<b style="background-color:'.$colors[$c].'"></b>';

So ist es richtig:
$replacement = '<b style="background-color:'.$colors[$c].'">'.$w.'</b>';

Gruß

Krueger

[Meike]

Super, ähhm Krueger (klingt nicht wirklich schön als Anrede...)

Den fehler habe ich selbst nicht gefunden, danke.
Aber was mich wundert ist, dass er sein Beispiel doch
anscheinend mit dem gleichen Code laufen lässt und es
funktioniert, oder sollte er wirklich 2 Versionen vom
Script nutzen?

http://simplecontent.net/phpsnippets/exec/1/markhits.html?highlight=1

Gruss
Meike