Moin! > Es sollen x Anwender in ihren Accounts PHP-Applikationen erstellen können und dafür Klassen und Funktionsbibliotheken includen dürfen, aber nicht im Klartext öffnen. 1. Du sollst im rechten Kasten Sand haben. 1. Du sollst im linkem Kasten nichts haben. 1. Du sollst in beiden Kästen genau das gleiche haben. Bedingung 1 geht. Bedienung 2 geht auch. Natürlich ist Bedingung 3 erfüllbar. Nur eben maximal 2 davon auf einmal. > 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. Wenn die Module nicht gelesen werden dürfen, dann müssen die eben über ein Protokoll mit den anderen kommunizieren. Hier bietet sich HTTP durchaus an (natürlich kann man auch FIFOS nehmen...). Also "einfach" den Apache mit einer zweiten Konfiguration starten und definieren wie die Skripte der Teilnehmer mit denen auf dem zweiten Apache kommunizieren ("API"). [Google macht es vor](https://developers.google.com/apis-explorer/#p/). Der 2. Server (keine eigene Hardware) bekommt einen eigenen Benutzer (nicht: www-data). Alternative: Kein zweiter Server nur ein eigenes Verzeichnis, Kommunikation der Skripte über https (einfach) oder FIFOs (schwieriger), dafür aber [mod_suhosin](https://suhosin.org/stories/index.html) konfigurieren. Jörg Reinholz

Moin! > Es sollen x Anwender in ihren Accounts PHP-Applikationen erstellen können und dafür Klassen und Funktionsbibliotheken includen dürfen, aber nicht im Klartext öffnen. 1. Du sollst im rechten Kasten Sand haben. 1. Du sollst im linkem Kasten nichts haben. 1. Du sollst in beiden Kästen genau das gleiche haben. Bedingung 1 geht. Bedienung 2 geht auch. Natürlich ist Bedingung 3 erfüllbar. Nur eben maximal 2 davon auf einmal. > 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. Wenn die Module nicht gelesen werden dürfen, dann müssen die eben über ein Protokoll mit den anderen kommunizieren. Hier bietet sich HTTP durchaus an (natürlich kann man auch FIFOS nehmen...). Also "einfach" den Apache mit einer zweiten Konfiguration starten und definieren wie die Skripte der Teilnehmer mit denen auf dem zweiten Apache kommunizieren ("API"). [Google macht es vor](https://developers.google.com/apis-explorer/#p/). Der 2. Server (keine eigene Hardware) bekommt einen eigenen Benutzer (nicht: www-data). Alternative: Kein zweiter Server nur ein eigenes Verzeichnis, Kommunikation der Skripte über http (einfach) oder FIFOs (schwieriger), dafür aber [mod_suhosin](https://suhosin.org/stories/index.html) konfigurieren. Jörg Reinholz

Moin! > Es sollen x Anwender in ihren Accounts PHP-Applikationen erstellen können und dafür Klassen und Funktionsbibliotheken includen dürfen, aber nicht im Klartext öffnen. 1. Du sollst im rechten Kasten Sand haben. 1. Du sollst im linkem Kasten nichts haben. 1. Du sollst in beiden Kästen genau das gleiche haben. Bedingung 1 geht. Bedienung 2 geht auch. Natürlich ist Bedingung 3 erfüllbar. Nur eben maximal 2 davon auf einmal. > Diese Module sollen den Host auch gar nicht verlassen, also scheidet eine Kompilation oder sonstige Aktion zum Unlesbar machen aus. Tja. Das geht eben nicht. Wer includen können soll, der **MUSS** definitiv auch lesen können. Wenn die Module nicht gelesen werden dürfen, dann müssen die eben über ein Protokoll mit den anderen kommunizieren. Hier bietet sich HTTP durchaus an (natürlich kann man auch FIFOS nehmen...). Also "einfach" den Apache mit einer zweiten Konfiguration starten und definieren wie die Skripte der Teilnehmer mit denen auf dem zweiten Apache kommunizieren ("API"). [Google macht es vor](https://developers.google.com/apis-explorer/#p/). Der 2. Server (keine eigene Hardware) bekommt einen eigenen Benutzer (nicht: www-data). Alternative: Kein zweiter Server nur ein eigenes Verzeichnis, Kommunikation der Skripte über http (einfach) oder FIFOs (schwieriger), dafür aber [mod_suhosin](https://suhosin.org/stories/index.html) konfigurieren. Jörg Reinholz

Moin! > Es sollen x Anwender in ihren Accounts PHP-Applikationen erstellen können und dafür Klassen und Funktionsbibliotheken includen dürfen, aber nicht im Klartext öffnen. 1. Du sollst im rechten Kasten Sand haben. 1. Du sollst im linkem Kasten nichts haben. 1. Du sollst in beiden Kästen genau das gleiche haben. Bedingung 1 geht. Bedienung 2 geht auch. Natürlich ist Bedingung 3 erfüllbar. Nur eben maximal 2 davon auf einmal. > Diese Module sollen den Host auch gar nicht verlassen, also scheidet eine Kompilation oder sonstige Aktion zum Unlesbar machen aus. Tja. Das geht eben nicht. Wer includen kann, der **MUSS** definitiv auch lesen können. Wenn die Module nicht gelesen werden dürfen, dann müssen die eben über ein Protokoll mit den anderen kommunizieren. Hier bietet sich HTTP durchaus an (natürlich kann man auch FIFOS nehmen...). Also "einfach" den Apache mit einer zweiten Konfiguration starten und definieren wie die Skripte der Teilnehmer mit denen auf dem zweiten Apache kommunizieren ("API"). [Google macht es vor](https://developers.google.com/apis-explorer/#p/). Der 2. Server (keine eigene Hardware) bekommt einen eigenen Benutzer (nicht: www-data). Alternative: Kein zweiter Server nur ein eigenes Verzeichnis, Kommunikation der Skripte über http (einfach) oder FIFOs (schwieriger), dafür aber [mod_suhosin](https://suhosin.org/stories/index.html) konfigurieren. Jörg Reinholz

Moin! > Es sollen x Anwender in ihren Accounts PHP-Applikationen erstellen können und dafür Klassen und Funktionsbibliotheken includen dürfen, aber nicht im Klartext öffnen. 1. Du sollst im rechten Kasten Sand haben. 1. Du sollst im Linkem Kasten nichts haben. 1. Du sollst in beiden Kästen genau das gleiche haben. Bedingung 1 geht. Bedienung 2 geht auch. Natürlich ist Bedingung 3 erfüllbar. Nur eben maximal 2 davon auf einmal. > Diese Module sollen den Host auch gar nicht verlassen, also scheidet eine Kompilation oder sonstige Aktion zum Unlesbar machen aus. Tja. Das geht eben nicht. Wer includen kann, der **MUSS** definitiv auch lesen können. Wenn die Module nicht gelesen werden dürfen, dann müssen die eben über ein Protokoll mit den anderen kommunizieren. Hier bietet sich HTTP durchaus an (natürlich kann man auch FIFOS nehmen...). Also "einfach" den Apache mit einer zweiten Konfiguration starten und definieren wie die Skripte der Teilnehmer mit denen auf dem zweiten Apache kommunizieren ("API"). [Google macht es vor](https://developers.google.com/apis-explorer/#p/). Der 2. Server (keine eigene Hardware) bekommt einen eigenen Benutzer (nicht: www-data). Alternative: Kein zweiter Server nur ein eigenes Verzeichnis, Kommunikation der Skripte über http (einfach) oder FIFOs (schwieriger), dafür aber [mod_suhosin](https://suhosin.org/stories/index.html) konfigurieren. Jörg Reinholz

Moin! > Es sollen x Anwender in ihren Accounts PHP-Applikationen erstellen können und dafür Klassen und Funktionsbibliotheken includen dürfen, aber nicht im Klartext öffnen. 1. Du sollst im rechten Kasten Sand haben. 1. Du sollst im Linkem Kasten nichts haben. 1. Du sollst in beiden Kästen genau das gleiche haben. Bedingung 1 geht. Bedienung 2 geht auch. Natürlich ist Bedingung 3 erfüllbar. Nur eben maximal 2 davon auf einmal. > Diese Module sollen den Host auch gar nicht verlassen, also scheidet eine Kompilation oder sonstige Aktion zum Unlesbar machen aus. Tja. Das geht eben nicht. Wer includen kann, der **MUSS** definitiv auch lesen können. Wenn die Module nicht gelesen werden dürfen, dann müssen die eben über ein Protokoll mit den anderen kommunizieren. Hier bietet sich HTTP durchaus an (natürlich kann man auch FIFOS nehmen...). Also "einfach" den Apache mit einer zweiten Konfiguration starten und definieren wie die Skripte der Teilnehmer mit denen auf dem zweiten Apache kommunizieren ("API"). [Google macht es vor](https://developers.google.com/apis-explorer/#p/). Der 2. Server bekommt einen eigenen Benutzer (nicht: www-data). Alternative: Kein zweiter Server nur ein eigenes Verzeichnis, Kommunikation der Skripte über http (einfach) oder FIFOs (schwieriger), dafür aber [mod_suhosin](https://suhosin.org/stories/index.html) konfigurieren. Jörg Reinholz