contao 4.4 system file path Änderung nicht möglich, was nun?

[Rentier06]

Hallo zusammen,
immer wieder in den Installationstools lese ich das die contao-manager.phar.php in einem Unterordner xyz/web stehen muss. Dieser muss dann auch als file-root angemeldet sein. Dies lässt mein Hoster (one.com) nicht zu.
Außerdem meldet der Webspace beim Aufruf "PHP PHAR extention not enabled". Zugriff auf die php.ini habe ich nicht.
Gibt es nun wiklich keine andere Möglichkeit 4.4 bei diesem Hoster zu installieren?
Wenn dem so ist, welche Hoster sind empfehlenswert?
Gruß vom Rentier(5=n)

[tab]

Also die gesammelten Erfahrungen mit diversen Hostern findest du hier: https://github.com/contao/contao-manager/wiki
Persönliche positive Erfahrungen habe ich bisher nur mit

1. Uberspace
2. Webgo

Zu Uberspace muss ich sagen, dass sich eine Domain nur durch einen Trick auf ein anderes Verzeichnis leiten lässt als /html. Dieser ist im Uberspace-Wiki und auch hier im Forum dokumentiert.
https://community.contao.org/de/show...-4-x-Uberspace
Zudem denke ich, dass dieser Trick wohl mit den zukünftigen Uberspaces (uberspace 7) so nicht mehr funktionieren wird. Ob es dann dazu eine Alternative gibt, kann ich nicht sagen, weil ich bisher noch keinen solchen Uberspace 7 getestet habe.
Zu Webgo kann ich sagen, dass es nach anfänglichen Startschwierigkeiten, die dann schnell behoben wurden, zumindest auf meinem Server läuft.

[xchs]

Zudem denke ich, dass dieser Trick wohl mit den zukünftigen Uberspaces (uberspace 7) so nicht mehr funktionieren wird. Ob es dann dazu eine Alternative gibt, kann ich nicht sagen, weil ich bisher noch keinen solchen Uberspace 7 getestet habe.

Aus eigener Erfahrung kann ich sagen, dass man auch auf einem U7 den DocumentRoot per Symlink auf den web/ Unterordner setzen kann. Ich konnte jedenfalls Contao 4.4 problemlos installieren.

[KloBoBBerLe]

Aus eigener Erfahrung kann ich sagen, dass man auch auf einem U7 den DocumentRoot per Symlink auf den web/ Unterordner setzen kann. Ich konnte jedenfalls Contao 4.4 problemlos installieren.

Aufbauend auf der Frage aus Punkt 3:

Ich bin hochgradig unsicher, ob die Installation in einem Unterverzeichnis mittels Weiterleitung anstelle der eigentlich vorgesehenen Änderung des Document Root auch tatsächlich im Sinne der Entwickler liegt.

Das Problem hierbei ist nämlich: Das erforderliche /web-Unterverzeichnis wird innerhalb eines bereits von Haus aus öffentlich zugänglichen Elternverzeichnisses (/htdocs, /www, /public) angelegt. Im Falle der angesprochenen Weiterleitung in das /web-Unterverzeichnis würde hierbei die Sicherheitsanweisung ignoriert werden, die besagt, dass lediglich das Unterverzeichnis /web öffentlich zugänglich sein soll, nicht jedoch dessen Elternverzeichnis.

Warning: For security purpose, the web/ folder should be the only one to be accessible by visitors.

Durch eine Weiterleitung anstelle der Anpassung des Document Root wäre nämlich auch das Elternverzeichnis und sämtliche bei der Installation darin abgelegte Contao-Verzeichnisse noch öffentlich zugänglich, was so nicht sein sollte.

Zum besseren Verständnis hier noch einmal die Verzeichnisstruktur, die bei der Installation angelegt wird:

|-- public (Elternverzeichnis, soll NICHT öffentlich sein!)
    |-- app (soll nicht öffentlich sein)
    |     |-- AppKernel.php
    |     |-- cache
    |     |-- config
    |     |-- logs
    |-- assets (soll nicht öffentlich sein)
    |-- files (soll nicht öffentlich sein)
    |-- system (soll nicht öffentlich sein)
    |     |-- config
    |     |    |-- localconfig.php
    |     |-- modules
    |-- templates (soll nicht öffentlich sein)
    |-- vendor (soll nicht öffentlich sein)
    |     |-- contao
    |     |-- symfony
    |-- web (soll öffentlich sein)
          |-- .htaccess (hidden file)
          |-- app_dev.php
          |-- app.php
          |-- install.php
          |-- share

Wenn nun also nicht nur das Verzeichnis /web, sondern auch bereits das Elternverzeichnis /public öffentlich zugänglich ist (inkl. aller enthaltenen Contao-Verzeichnisse), dann wäre dies gemäß der obigen Warnung unzulässig. Eine offizielle Aussage hierzu wäre unter Umständen hilfreich.

Viele Grüße und besten Dank!
KloBoBBerLe

[xchs]

Wenn der DocumentRoot für die Hauptdomain fix vorgegeben ist, könntest Du das gewünschte Zielverzeichnis ev. auch per Symlink referenzieren. Hast Du einen Shell-Zugang?

[KloBoBBerLe]

Hallo xchs,

vielen herzlichen Dank für Deine Antwort!

Wenn der DocumentRoot für die Hauptdomain fix vorgegeben ist, könntest Du das gewünschte Zielverzeichnis ev. auch per Symlink referenzieren. Hast Du einen Shell-Zugang?

Per Symlink könnte die Contao-Installation vielleicht tatsächlich funktionieren, doch das Kernproblem bleibt davon ja völlig unberührt:

Alle Contao-Verzeichnisse außer /web sollen laut Warnhinweis der Öffentlichkeit verwehrt bleiben. Dementsprechend darf auch lediglich das /web-Verzeichnis in einem öffentlich zugänglichen Verzeichnis innerhalb des Document Roots liegen, alle anderen Verzeichnisse müssen eine Ebene darüber (im nicht-öffentlichen Elternverzeichnis) platziert sein. Der Contao-Manager kann dementsprechend ausschließlich im ersten Verzeichnis des Document Root mit dem Namen /web installiert werden, damit die anderen Contao-Dateien eine Ebene darüber und somit außerhalb des öffentlichen Zugriffs sind.

Diese Trennung funktioniert jedoch nicht, wenn das komplette Contao in einem Unterordner des Document Root installiert wird, weil dann nachfolgend alle Verzeichnisse innerhalb des Document Root liegen würden und somit alle öffentlich zugänglich sind.

Verstehst Du, wie ich meine?

Vielleicht verstehe ich aber auch diese Warnmeldung völlig falsch - wer weiß.

[xchs]

doch das Kernproblem bleibt davon ja völlig unberührt

Wieso denn?

Wenn Dein Hoster den DocumentRoot der Hauptdomain fix vorgibt, wäre das Setzen eines Symlinks imho die beste Lösung.

Alle Contao-Verzeichnisse außer /web sollen laut Warnhinweis der Öffentlichkeit verwehrt bleiben.

Ja, und genau das wäre dann ja der Fall, wenn Du einen Symlink auf das web/ Unterverzeichnis Deiner Contao-Installation setzt.

Hast Du einen Shell-Zugang? Falls ja, kann ich Dir das gerne konfigurieren.

[KloBoBBerLe]

Wieso denn?

Wenn Dein Hoster den DocumentRoot der Hauptdomain fix vorgibt, wäre das Setzen eines Symlinks imho die beste Lösung..

Schande über mein Haupt - ich bin Techniker, kein Informatiker. Ich dachte, Du meintest mit "Weiterleitung" irgend eine Konfiguration in der zugehörigen .htaccess-Datei. Jetzt musste ich gerade erst einmal nachlesen, was denn ein Symlink genau macht.

Hast Du einen Shell-Zugang? Falls ja, kann ich Dir das gerne konfigurieren.

Ich werde mich mal schlau lesen und dann bei Bedarf sehr gerne auf Dein überaus nettes Angebot zurück kommen! Vielen Dank!

[xchs]

Kein Problem.

Ich bin relativ sicher, dass Du das mit dem Symlink usw. selbst hinbekommst (weil es eigentlich keine große Hexerei ist) und ansonsten kannst Du Dich – wie gesagt – gerne per PN melden.

[tab]

Würde mich auch interessieren, wie du das mit dem Symlink meinst. Wie das bei uberspace geht ist mir klar, aber hier ist der Webspace anders strukturiert. Zudem hilft uberspace bei der Sache aktiv nach mit einer .htaccess in einem übergeordneten Verzeichnis des User-Webspaces, die die dortige Lösung mit dem Symlink überhaupt erst ermöglicht. Das gilt jetzt für den "alten" uberspace. Wie machst du das bei dem uberspace 7? Oder ist da, entgegen der Dokumentation, doch auch eine solche .htaccess vorhanden - oder eine andere Lösung realisiert - welche die Verlegung der document root in ein anderes Verzeichnis als /var/www/virtual/<username>/html ermöglicht? Da muss ich mir mal über Weihnachten einen uberspace 7 klicken.

Wegen der Bedenken mit der öffentlichen Zugänglichkeit des Contao Installationsverzeichnisses: Die Zugänglichkeit ist ja je nach Verzeichnisstruktur im Webspace mehr oder minder theoretisch. Es muss tatsächlich eine URL geben, die diese Verzeichnisse bzw Dateien darin auch ausliefern. Wenn das gegeben ist, dann ist es ein reales Problem, weil dann zum Beispiel Datenbankzugangsdaten öffentlich zugänglich wären. Das könnte dann - zumindest von anderen Usern auf dem selben Server, eventuell auch für andere - ausgenutzt werden, um Zugriff auf die Datenbank zu erlangen und damit Unfug zu treiben, indem Datenbankeinträge manipuliert werden. Oder auch, um Dateien aus einem vermeintlich geschützten Verzeichnis auszulesen (z.B. in Mitgliederverzeichnissen).

Grundsätzlich halte ich es aber für ungünstig, wenn ein Hosting keine "echte" Änderung der document root einer Domain ermöglicht.

[xchs]

@tab: Bei Uberspace 7 sind jetzt übrigens wieder Pseudo-DocumentRoots möglich – so wie Du das von U6 kennst. Also braucht es diesbezüglich auch keine "Verrenkungen" mehr.

[tab]

Das ist gut. Obwohl das natürlich seit jeher nur eine Krücke ist. Aber wenigstens eine funktionierende Krücke.

[Rentier06]

Vielen Dank für diese lebhafte Diskussion. Auch wenn ich nicht verstehe, was mit Uberspace U7 oder U6 gemeint ist. Mit meinem Hoster bin ich jetzt endlich klar gekommen.
Mit dem .taccesss
#Rewrite everything to subfolder
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/web
Rewriterule ^(.*)$ web/$1 [L]
Läuft die Umleitung problemlos.