Hallo und guten Morgen, > > Diese Module sollen den Host auch gar nicht verlassen, also scheidet eine Kompilation oder sonstige Aktion zum Unlesbar machen aus. > > Tja. Das obiges (includen:ja / lesen:nein) geht eben nicht. Wer includen können soll, der **MUSS** definitiv auch lesen können. Das sehe ich anders! PHP wrd auf dem Webserver ausgeführt. Hierzu kann Code aus dem Reich von Domain example.org kommen und es kann Code aus dem Reich von /usr/share/php/commoncode/ kommen. Dieser Code kann vom Webserver-Benutzer zwar zur Ausführung geladen werden, aufgrund der Eigenart von PHP aber nicht durch die normalen PHP-Dateisystemfunktionen geöffnet werden. Exec & Co kann man ausschalten. Vielleicht liegt das Missverständis an der üblicherweise falschen Sprechweise "include lädt den Code an die Stelle im Script...". Tut es ja gar nicht. Es lädt den Code an die Stelle im Arbeitsspeicher! Und der ist mMn mit PHP-Mitteln nicht abbildbar für den Programmierungs-Anwender. Und hier hat Dedlfix ja auch Recht: Ich _lasse_ ja ausführen. Der Interpreter ist doch schon ein entferntes Programm für mich. Der läuft ja nicht auf meinem Client, sondern eben auf dem Server. Wenn ich schon etwas schlauer wäre, dann würde ich eine Extension für PHP schreiben und der Fall wäre erledigt. Die müsste dann aber jedes Mal neu eincompiliert werden, wenn sich etwas ändert. Ist auch nicht so toll! Grüße TS

Hallo und guten Morgen, > > Diese Module sollen den Host auch gar nicht verlassen, also scheidet eine Kompilation oder sonstige Aktion zum Unlesbar machen aus. > > Tja. Das obiges (includen:ja / lesen:nein) geht eben nicht. Wer includen können soll, der **MUSS** definitiv auch lesen können. Das sehe ich anders! PHP wrd auf dem Webserver ausgeführt. Hierzu kann Code aus dem Reich von Domain example.org kommen und es kann Code aus dem Reich von /usr/share/php/commoncode/ kommen. Dieser Code kann vom Webserver-Benutzer zwar zur Ausführung geladen werden, aufgrund der Eigenart von PHP aber nicht durch die normalen PHP-Dateisystemfunktionen geöffnet werden. Exec & Co kann man ausschalten. Vielleicht liegt das Missverständis an der üblicherweise falschen Sprechweise "include lädt den Code an die Stelle im Script...". Tut es ja gar nicht. Es lädt den Code an die Stelle im Arbeitsspeicher! Und der ist mMn mit PHP-Mitteln nicht abbildbar für den Programmierungs-Anwender. Und hier hat Dedlfix ja auch Recht: Ich _lasse_ ja ausführen. Der Interpreter ist doch schon ein entferntes Programm für mich. Der läuft ja nicht auf meinem Client, sondern eben auf dem Server. Grüße TS

Hallo und guten Morgen, > > Diese Module sollen den Host auch gar nicht verlassen, also scheidet eine Kompilation oder sonstige Aktion zum Unlesbar machen aus. > > Tja. Das obiges (includen:ja / lesen:nein) geht eben nicht. Wer includen können soll, der **MUSS** definitiv auch lesen können. Das sehe ich anders! PHP wrd auf dem Webserver ausgeführt. Hierzu kann Code aus dem Reich von Domain example.org kommen und es kann Code aus dem Reich von /usr/share/php/commoncode/ kommen. Dieser Code kann vom Webserver-Benutzer zwar zur Ausführung geladen werden, aufgrund der Eigenart von PHP aber nicht durch die normalen PHP-Dateisystemfunktionen geöffnet werden. Exec & Co kann man ausschalten. Vielleicht liegt das Missverständis an der üblicherweise falschen Sprechweise "include lädt den Code an die Stelle im Script...". Tut es ja gar nicht. Es lädt den Code an die Stelle im Arbeitsspeicher! Und der istmMn mit PHP-Mitteln nicht abbildbar für den Programmierungs-Anwender. Und hier hat Dedlfix ja auch Recht: Ich _lasse_ ja ausführen. Der Interpreter ist doch schon ein entferntes Programm für mich. Der läuft ja nicht auf meinem Client, sondern eben auf dem Server. Grüße TS

Hallo und guten Morgen, > > Diese Module sollen den Host auch gar nicht verlassen, also scheidet eine Kompilation oder sonstige Aktion zum Unlesbar machen aus. > > Tja. Das obiges (includen:ja / lesen:nein) geht eben nicht. Wer includen können soll, der **MUSS** definitiv auch lesen können. Das sehe ich anders! PHP wrd auf dem Webserver ausgeführt. Hierzu kann Code aus dem Reich von Domain example.org kommen und es kann Code aus dem Reich von /usr/share/php/commoncode/ kommen. Dieser Code kann vom Webserver-Benutzer zwar zur Ausführung geladen werden, aufgrund der Eigenart von PHP aber nicht durch die normalen PHP-Dateisystemfunktionen geöffnet werden. Exec & Co kann man ausschalten. Vielleicht liegt das Missverständis an der üblicherweise falschen Sprechweise "include lädt den Code an die Stelle im Script...". Tur es ja gar nicht. Es lädt den Code an die Stelle im Arbeitsspeicher! Und der istmMn mit PHP-Mitteln nicht abbildbar für den Programmierungs-Anwender. Und hier hat Dedlfix ja auch Recht: Ich _lasse_ ja ausführen. Der Interpreter ist doch schon ein entferntes Programm für mich. Der läuft ja nicht auf meinem Client, sondern eben auf dem Server. Grüße TS

Hallo und guten Morgen, > > Diese Module sollen den Host auch gar nicht verlassen, also scheidet eine Kompilation oder sonstige Aktion zum Unlesbar machen aus. > > Tja. Das obiges (includen:ja / lesen:nein) geht eben nicht. Wer includen können soll, der **MUSS** definitiv auch lesen können. Das sehe ich anders! PHP wrd auf dem Webserver ausgeführt. Hierzu kann Code aus dem reich von Domain example.org kommen und es kann Code aus dem Reich von /usr/share/php/commoncode/ kommen. Dieser Code kann vom Webserver-Benutzer zwar zur Ausführung geladen werden, aufgrund der Eigenart von PHP aber nicht durch die normalen PHP-Dateisystemfunktionen geöffnet werden. Exec & Co kann man ausschalten. Vielleicht liegt das Missverständis an der üblicherweise falschen Sprechweise "include lädt den Code an die Stelle im Script...". Tur es ja gar nicht. Es lädt den Code an die Stelle im Arbeitsspeicher! Und der istmMn mit PHP-Mitteln nicht abbildbar für den Programmierungs-Anwender. Und hier hat Dedlfix ja auch Recht: Ich _lasse_ ja ausführen. Der Interpreter ist doch schon ein entferntes Programm für mich. Der läuft ja nicht auf meinem Client, sondern eben auf dem Server. Grüße TS