Providerwechsel: Script streikt

radarin

radarin

Angesehenes Mitglied
Hallo Liste.
Ich hab meine Domain von einem privaten Server zu Hostpoint gezügelt. Leider muss ich feststellen, dass diverse Scripts jetzt ihren Dienst versagen. Z.B. das folgende Script, das eine Versionskontrolle macht wenn ein User das Script auf seinem Server verwendet und auf meinem Server ein File mit der Versionsnummer ausgelesen werden soll, um die Versionen zu vergleichen:

CODE
function get_version() {

// Position des Checkers
$path_checker = "http://www.darin.ch/vsinfo/gallery.vs.txt";

// Öffnen einer URL möglich?
if (ini_get('allow_url_fopen') == 1) {

$fp = @fopen($path_checker,"r");
if ($fp) {
return fgets($fp,255);
fclose($fp);
} else {
return "";//Verbindungsfehler
}
} else {
return "";//Version kann nicht automatisch ermittelt werden
}
}



Wo liegt das Problem? Erlaubt mein Server die Anfrage nach aussen nicht? Dann nützt das ganze Script nichts, wenn ich mich nicht darauf verlassen kann dass die Abfrage auf diese Art und weise auch möglich ist. Oder Verweigert mein Server die Anfrage? Was müsste ich da ändern. Ich hab eine eigene php.ini für meine Domain.

Gruss René
 
QUOTE (radarin @ Sa 18.11.2006, 18:45)Wo liegt das Problem?

Zuallererst in dem miserablen Code, der zwar brav verzweigt, aber nicht sagt, warum er nicht will.

Und wenn das Script nicht mitteilt, wo es abbricht, dann ist alles spätere nur Herumraten.
 
QUOTE return "";//Verbindungsfehler
return "";//Version kann nicht automatisch ermittelt werden


Gibt das Script eine Fehlermeldung zurück?

Falls nicht, kannst du die beiden Zeilen oben so editieren, dass dir die Funktion zumindest zurückgibt wo sie beendet wird.

 
Das Script soll einfach nur seine Arbeit machen. Entweder den Wert einlesen um diesen zu verarbeiten, aber auf keinen Fall eine Fehlermeldung dem Besucher der Seite anzeigen. Den geht die Fehlfunktion nix an, ausserdem möchte ich nicht die Webseite derer verunstalten die das Script einsetzen.

Der Fehler entsteht hier:

return "";//Version kann nicht automatisch ermittelt werden

Somit liefert ini_get('allow_url_fopen') keine 1
 
ich denke mal, dann solltest du in der php.ini

allow_url_fopen=Off

nach

allow_url_fopen=On

ändern.
Gruss

André
 
QUOTE Das Script soll einfach nur seine Arbeit machen. Entweder den Wert einlesen um diesen zu verarbeiten, aber auf keinen Fall eine Fehlermeldung dem Besucher der Seite anzeigen. Den geht die Fehlfunktion nix an, ausserdem möchte ich nicht die Webseite derer verunstalten die das Script einsetzen.


Die Fehlermeldung soll auch nicht für den Besucher bestimmt sein, sondern für dich, damit du siehst wann und wo der Fehler entsteht (evtl. sogar auch warum). Und wenn du in ein Forum postest regen die Fehlermeldungen die Kristallkugeln der anderen User etwas an, damit sie helfen können
wink.gif
 
QUOTE (radarin @ Sa 18.11.2006, 19:36)Das Script soll einfach nur seine Arbeit machen. Entweder den Wert einlesen um diesen zu verarbeiten, aber auf keinen Fall eine Fehlermeldung dem Besucher der Seite anzeigen. Den geht die Fehlfunktion nix an, ausserdem möchte ich nicht die Webseite derer verunstalten die das Script einsetzen.


Bei so einer Haltung solltest Du es unterlassen, an andere Leute Code zu verteilen.

Ein Script sollte nichts (!) tun - außer, wenn alle Bedingungen erfüllt sind, die es zu seinem korrekten Durchlaufen benötigt. Wenn also bei jemandem, der das Script einsetzt, ebenfalls allow_url_fopen = False ist, dann muß das Script eine hinreichend deutliche Fehlermeldung ausgeben. Ansonsten ist es ein miserables und gefährliches Script, da es eine Zeitbombe darstellt.

Denn dann gehen der, der das Script einsetzt, und Du davon aus, daß alle eingesetzten Varianten in der aktuellen Version genutzt werden - und in Wirklichkeit gibt es diverse nicht aktualisierte Scripts, da die Provider - aus sehr guten Gründen - allow_url_fopen unterbinden.




QUOTE (radarin @ Sa 18.11.2006, 19:36)Der Fehler entsteht hier:

return "";//Version kann nicht automatisch ermittelt werden

Somit liefert ini_get('allow_url_fopen') keine 1

Dann ist doch klar, wo das Problem liegt. Und wenn das Script bereits bei Leuten eingesetzt wird, dann funktioniert es dort jetzt schon nicht. Die Leute denken, es würde automatisch aktualisiert werden - erst jetzt stellst Du aufgrund deines eigenen Serverwechsels fest, daß es ein Problem gibt. Und schon gibt es die Bomben.
 
@jAuer:

Die Bemerkung von wegen 'miserabler Code' ist doch etwas Provokant. Davon abgesehen stammt dieser Code von einem User dieser Platform.

Das Script soll zwei Werte vergleichen. Den im Script und den im Textfile auf meiner Domain. Ist der Wert auf meiner Domain höher, soll der Betreiber des Scriptes eine eMail bekommen oder es soll ein Hinweis angezeigt werden (auch diese ist eigentlich für den Seitenbetreiber bestimmt, weniger für die User). Funktioniert das Script nicht soll einfach nichts passieren. Ein Mail nach dem Anderen, vonwegen, du, die Versionskontrolle funktioniert nicht, mich würde das ärgern.

Aus dieser Sicht hat das Script keine einzige Zeile zu wenig. Natürlich hab ich mir ein echo() eingebaut um zu sehen was fehl läuft. Blöd von mir das ich vergessen habe dies zu erwähnen.

Dass das Script Probleme macht habe ich festgestellt, dass ich die Meldung erhalte, das Script kann aktualisiert werden, weil der Wert im Vergleich leer geblieben ist, der von meiner Domain kommen sollte.

Ich verlange für mein Script (Verzeichnisse auslesen und die darin enthaltenen Fotos als Gallery darstellen) kein Geld. Somit muss es mich nicht interessieren wer das Script einsetzt. Ich möchte einfach nur eine Funktion die ZUVERLÄSSIG die Version überprüft, ohne dass ich eine Userliste führen muss um diese ggf. zu Informieren wenn es eine Neuerung gibt.

Wenn ich dazu also die Funktion 'allow_url_fopen' verwenden soll, muss ich mich darauf verlassen können, dass diese absolut zum verfügbaren Befehlssatz von PHP gehört.

Du schreibst, die Provider hätten gute Gründe allow_url_fopen auf OFF zu setzen? (ist bei mir auch der Fall) Warum sollten die das tun? Wäre es angebracht bei meinem Provider diesbezüglich nachzufragen ob ich diese Funktion auf ON setzen darf?

Offensichtlich funktioniert dieses Script nur Providerabhängig. Somit ist es für meinen Einsatz absolut untauglich. Wenn es keine andere Möglichkeit gibt eine solche Prüfung zu automatisieren, dann bleibt mir nur noch der Hinweis, schaut selber auf meiner Page nach ob es Updates gibt oder tragt Euch im Newsletter ein...

Gruss René
 
@Jürgen:

Ich denke, wenn man das von der Userseite aus betrachtet, dann ist ein Code ala:

QUOTE
$fp = @fopen($path_checker,"r");
if ($fp) {
return fgets($fp,255);
fclose($fp);
} else {
return array('-', 'Fehler: Eine Verbindung zum Server war nicht möglich.');//Verbindungsfehler
}


nicht so schlimm. Man ünterdrückt zwar die PHP-Standardfehlermeldung, kann dafür aber den User einen Satz wie "Eine Verbindung zum Server war nicht möglich." liefern, der für computerunerfahrene Benutzer verständlich ist.

Also, als "miserabel" würde ich diese Vorgehensweise nicht beschreiben. (Und nur um Spekulationen vorzugreifen: Mein Code ist es auch nicht. ;-)
 
Du setzt dich erst jetzt damit auseinander, daß fopen ein Sicherheitsrisiko darstellt?

Dann solltest Du in den nächsten ein bis zwei Jahren die Finger davon lassen, an andere Personen Code zu verteilen, der von diesen auf Webservern eingesetzt wird.

Daß der obige Code miserabel ist, da er auf jegliche Fehlerbehandlung verzichtet (diese ist auch noch auskommentiert), das ist offensichtlich. Derjenige, der das Script einsetzen will, erhält noch nicht einmal einen Hinweis, daß es nicht wie gewünscht funktioniert und denkt deshalb, es sei alles in Ordnung (deshalb ist der Hinweis von @Moritz da gerade der Schritt von 'miserabel' zu 'brauchbar' - natürlich gibt man eine unverfängliche Meldung aus, die aber darauf hinweist, daß etwas klemmt).

QUOTE Ich verlange für mein Script (Verzeichnisse auslesen und die darin enthaltenen Fotos als Gallery darstellen) kein Geld. Somit muss es mich nicht interessieren wer das Script einsetzt. Ich möchte einfach nur eine Funktion die ZUVERLÄSSIG die Version überprüft, ohne dass ich eine Userliste führen muss um diese ggf. zu Informieren wenn es eine Neuerung gibt.
...
Offensichtlich funktioniert dieses Script nur Providerabhängig. Somit ist es für meinen Einsatz absolut untauglich.


Und warum verteilst Du es dann? Offenbar heißt 'kostenlos' auch 'verantwortungslos'.

Genau das ist das, was mich bei all diesen PHP-Bastlern so stört: Daß hochkritischer Code ohne jedes Verständnis von Sicherheit und ohne irgendeine Verantwortung für das eigene Tun fleißig verteilt wird. Und es ist völlig egal, wer dir Codevorschläge macht: Verteilst Du es, dann bist Du für den Code verantwortlich.

An der Stelle wünsche ich mir manchmal, daß es keine OpenSource, sondern nur - wie vor fünfzehn Jahren - teure Entwicklungsumgebungen geben würde. Dann würden nämlich solche Codes nicht auch noch um die halbe Welt gehen.

PS: Was passiert eigentlich, wenn dein Server gehackt werden würde und jemand dorthin, wo die aktuelle Version des Scripts liegt, einen hochkritischen Code deponiert, der alles mögliche installiert? Alle deine Nutzer laden das dann brav nach und führen den Code aus.
 
Diese Diskusion treibt meinen Adrenalinspiegel gewaltig in die Höhe. Ich muss da wohl etwas weiter ausholen.

Um für meine Fotogallery's wie ein Wilder HTML Seiten zusammen zu kopieren, das wurde mir einfach zu blöd. Der Bequemste Schritt war also nach einem geeigneten Script zu suchen. Die Probleme, teilweise schlecht anpassbar, Uploads über Formulare bei grosser Anzahl an Bildern viel zu umständlich, oder eben die Probleme, dass der Provider Funktionen unterbindet oder z. B. die GDLibery nicht installiert hat. Ich brauchte also ein Script das Unabhängig von nicht kompletten Serverinstallationen oder Sicherheitseinstellungen arbeitet.

Das Einfachste für mich ist, die Fotos lokal auf die gewünschte Grösse zu rechnen (Grossansicht und Thumbnail) und diese in Verzeichnisse mittels FTP hochzuladen. Mein Script macht also nichts anderes und liest die Verzeichnisse aus. Sind weitere Unterverzeichnisse drinn oder Bilder? Sind Thiumbnails vorhanden? Daraus resultiert die Darstellung mit Titeln, Navigation, Diashow, etc.

Was die Versionskontrolle angeht, so steht da allow_url_fopen am Pranger, wo ich jetzt nicht weiss ob die Verwendung dieses Befehls gefährlich ist, oder die Existenz dessen fahrlässig.
Auf der anderen Seite die Meinung, muss da eine Fehlermeldung ausgegeben werden oder nicht. NEIN, es braucht da keine Meldung für den User. Der bekommt auf der Einstiegsseite eine Verzeichnisliste zu sehen, und mehr braucht er nicht. Was soll er mit dem Hinweis, keine Verbindung zum Server möglich? Die ist für ihn absolut nicht relevant und nur verwirrend.

Ich weiss, im Zusammenhang mit PHP gibt es offensichtlich so einige Sicherheitslücken, und wenn irgend ein krankes Hornochse (sorry für den Ausdruck, es folgt später noch ein ähnlicher) böse Dinge tun will, so wird er früher oder später immer eine Möglichkeit finden.

Wenn ich in der Befehlsreferenz von PHP nachlese was dieses kann, dann steht da nur wie die Befehle lauten, da steht nicht, allow_url_fopen ist gefährlich, da steht nicht, include() ist heimtückisch, da steht nicht mail() kann massiv manipuliert werden.

Und genau das kotzt mich ganz gewaltig an. Es wird nach Handbuch gearbeitet und irgendwann erfahre ich, schau mal, da musst du das anders machen, weil böse Jungs (und auch Mädchen?) damit ganz gemeine Sachen anstellen können. Toll, wie wäre es wenn man von Anfang an über diese Problematiken aufmerksam macht?

Ich bin nicht Informatiker und ich nutze einen Bruchteil der Funktionen die PHP bietet. Und mir fehlt da das umfangreiche Hackerwissen um mich in diese kranken Saboteurenhirne hineinversetzen kann.

allow_url_fopen, na und, was soll ich mir darüber Gedanken machen? Keine! Ausser jemand sagt mir du musst hier aus diesen Gründen das Beachten und so Vorkehrungen treffen.

AAlso sollte ich diesen Befehl nicht verwenden, oder gibt es eine Möglichkeit das Script zu zwingen nur das zu machen was ich will?

Ich rufe meine Seiten meist über immer die selbe Indexseite auf und Include den Inhalt. Da ist es für mich am einfachsten gleich den Namen der Seite in die URL zu schreiben. Warum auch nicht? Offenbar wegen diesen vorhin erwähnten Kranken. Also prüfe ich erst ob das Dokument exisiert das in der URL includet werden will, oder ich definiere in einem array alle seiten die legal sind oder ich arbeite mit nummern und zuordnungen der seiten, was dann allerdings im unterhalt etwas umständlicher wird.

Konstruktive Kritik ist immer willkommen, Bemerkungen wie miserabler Code helfen nicht weiter.

Und jetzt gehe ich ein Bier trinken, danach entferne ich die Updatekontrolle aus dem Script. Muss der User sich eben selber um Aktualität bemühen, schliesslich zwinge ich niemanden diesen zu verwenden.

Gruss René
 
Solange deine Applikation dicht ist, stellt allow_url_fopen kein Risiko dar, ebenso wie mail() etc... Du darfst jedoch auf keinen Fall ungefilterte/gesicherte Variabeln dort einbinden. Wenn ein direkter Zugiff auf diese Funktionen möglich ist, kann der Angreifer im Beispiel von allow_url_fopen ein eigenes PHP-Script von einer beliebeigen Quelle einschleussen, welches dann von deinem Script ganz normal durchgearbeitet wird. Was damit möglich wäre, dürfte klar sein..

In einem ungesicherten Mail() kann z.B. jeder sehr einfach weitere, beliebige Empfänger/CC's/BCC's etc einfügen. Die Folge dürfte auch hier klar sein..

Die Grundversion des Scripts stammt übrigens ursprünglich von mir. Das war aber allerdings eher als Idee gedacht, nicht als Lösung ;-). Ich hatte dort aber sicherlich keinen leeren Return's drin ;-)
Da PHP4 noch keine Exeptions kennt, ist das Abfangen von Fehlern relativ harzig, und lässt sich mit der PHP-Defaultinstallation kaum anders regeln als oben.

Mit PHP5 lässt sich da zum Glück seriöser Arbeiten. 95% aller Provider bieten aber noch immer nur PHP4 an, leider. Daher wird solcher Code leider nicht so schnell aussterbern..
 
QUOTE (Moritz_Klussmann @ Sa 18.11.2006, 22:14)
QUOTE
$fp = @fopen($path_checker,"r");
if ($fp) {
return fgets($fp,255);
fclose($fp);
} else {
return array('-', 'Fehler: Eine Verbindung zum Server war nicht möglich.');//Verbindungsfehler
}


Diese Variante ist typentechnisch kriminell
rolleyes.gif
. Die kriegst im Normalfall einen String zurück, bei einem Fehler dagegen ein array..
 
Danke für den Link, interessanter Text.

Aber wie gesagt, wenn 'allow_url_fopen' nicht zum selbstverständlichen Standard gehört, ist es für meine Zwecke untauglich. Verzichte ich eben auf die aut. Überprüfung.
 
Diese Probleme sind kein Problem von PHP. Heutzutage gibt es in jeder höheren Programmiersprache die Möglichkeit, Daten per http-Protokoll nachzuladen, sie zu speichern und sie anschließend als Code auszuführen. Seit etwa 1996/97 laufen die Diskussionen darüber im Webbereich - Stichwort Applets, das ist nichts anderes.

Ein Handbuch ist für Leute mit umfangreichen Kenntnissen. Ein Handbuch für Medikamente kann von einem Laien auch nicht verstanden werden. Wenn Du schreibst
QUOTE Und genau das kotzt mich ganz gewaltig an. Es wird nach Handbuch gearbeitet und irgendwann erfahre ich, schau mal, da musst du das anders machen, weil böse Jungs (und auch Mädchen?) damit ganz gemeine Sachen anstellen können. Toll, wie wäre es wenn man von Anfang an über diese Problematiken aufmerksam macht?


Es wäre dein Job, dich über die Probleme zu informieren, bevor Du Scripte an andere verteilst. Und wie Du reagierst, wenn man dich auf die Probleme aufmerksam macht, das ist ja hier zu sehen.


QUOTE Der Bequemste Schritt war also nach einem geeigneten Script zu suchen.

Wenn dir dein Auto zu langsam ist, tunst Du es dann auch? Mit gutem Grund erlischt dann die Betriebsgenehmigung (weiß nicht genau, wie das heißt, bin kein Autofahrer), weil ein solches Auto im öffentlichen Verkehr für andere tödlich sein kann. Auf deinem Privatgrundstück dürftest Du ein solches Auto wahrscheinlich verwenden.


QUOTE Ich bin nicht Informatiker und ich nutze einen Bruchteil der Funktionen die PHP bietet. Und mir fehlt da das umfangreiche Hackerwissen um mich in diese kranken Saboteurenhirne hineinversetzen kann.


Und warum verteilst Du dann Code an andere? Code, der womöglich für Sql-Injektionen oder Mailinjektionen empfänglich ist? Ich verteile auch keine selbst gebauten Autos oder selbst zusammengebraute Medikamente.

Diese ganzen Dinge sind Jahre alt - Prinzip der minimalen Rechte, trau keinen Benutzereingaben usw. Ein paar Literaturangaben gibt es am Ende von diesem Artikel, der auch nicht mehr der neueste ist. Aber das, was da steht, veraltet auch nicht so schnell.
 
QUOTE (Alonso @ So 19.11.2006, 3:27)Diese Variante ist typentechnisch kriminell
rolleyes.gif
. Die kriegst im Normalfall einen String zurück, bei einem Fehler dagegen ein array..

Hast natürlich Recht. Es ging aber um die Behandlung in der Else-Schleife. Da habe ich mir, ehrlich gesagt, gar nicht angeschaut, was innerhalb von den "if-Klammern" steht.

So, der Thread driftet hier aber leider von konstruktiver Kritik in "dein-Code-ist-kacke"-Gehabe ab. Also, alle mal beruhigen!
 
fopen ist leider bei den meisten deaktiviert...

Dass ist auch einer der Gründe warum ich nun einen eigenen Server habe.

Hat Hostpoint Plesk?
 
QUOTE (sd12 @ So 19.11.2006, 16:49) fopen ist leider bei den meisten deaktiviert...

Dass ist auch einer der Gründe warum ich nun einen eigenen Server habe.

Hat Hostpoint Plesk?

Nach meinen Erfahrungen hat ein guter Provider allow_url_fopen auf On. Sind eher die, die nichts davon verstehen, die es deaktiviert haben.

Genauso wie in dem Text, "Den safe_mode setzt ihr am besten auf "On". Das ist nicht unbedingt nötig, aber schaden kann's nicht.". Wenn man keine Ahnung hat dann ..., wenn man Ahnung hat dann bitte auch erklären und nicht nur "schaden kanns nicht".
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben