Version 4.9 | Fehler nach Pfadänderung | Verzeichnis /web

Hallo zusammen!

Die letzten Jahre hatte ich keine gröberen Probleme und konnte vieles mit der Recherche im Forum lösen, aber nun fürchte ich, ich habe einen mächtigen Bock geschossen. Hoffentlich haben vor allem Experten wie Spooky oder tab ein wenig Zeit und Muße, um sich dem Problem zu widmen.
Habe leider erst nach Fertigstellung der Seite https hinzugefügt und daher die Weiterleitung nach /web, wo ja hininstalliert wird, aufgehoben, damit die Validierungsdatei im Root-Verzeichnis gefunden werden kann. Nachdem das erledigt war, wollte ich wieder den Pfad nach domain/web ändern. Die Anmeldeseite zum Backend erscheint auch, aber es kommt nach versuchter Anmeldung die Fehlermeldung: Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann.
Ich kann sogar den Contao-Manager starten und die Systemprüfung sagt mir, das alles in Ordnung ist, aber ich kann mich nun nicht mehr ins Backend einloggen. Ich habe u. a. auch bemerkt, dass die htaccess ein Änderungsdatum hat, das dem meiner Umstellung im KAS von All-Inkl entspricht. Ich hab aber keine Ahnung, ob es "nur" daran liegt und was richtigerweise in dieser Datei stehen sollte, oder ob ich noch anderweitig Mist gebaut hab. Ich hoffe, es ist halbwegs verständlich erklärt, was genau mein Problem ist, und dass ich das Projekt nicht in die Tonne treten muss.

Danke schon mal für eure Hinweise!

Wenn du selbst keine Anpassungne an der .htaccess gemacht hast, könntest du diese löschen und über den Contao Manager die Abhängigkeiten wieder installieren lassen. Das stellt den Originalzustand der .htaccess wieder her. Außerdem solltest du dann den Browser Cache und die Cookies der Domain löschen.

Zitat:

---

Zitat von Spooky

Wenn du selbst keine Anpassungne an der .htaccess gemacht hast, könntest du diese löschen und über den Contao Manager die Abhängigkeiten wieder installieren lassen. Das stellt den Originalzustand der .htaccess wieder her. Außerdem solltest du dann den Browser Cache und die Cookies der Domain löschen.

---

Vielen Dank für die rasche Antwort! Werd den Vorschlag sofort probieren, an der Datei selbst hab ich nie was geändert. Nur der Vollständigkeit halber: Mit Cookies der Domain meinst du was genau? Die allgemeinen Cookies im Browser oder gibts im Manager bzw. in Contao 4 noch separate Cookies, die manuell zu löschen sind? Hab bisher nur mit 3.x gearbeitet, daher die vielleicht etwas sinnlos erscheinende Frage. Früher musste man ja auch gewisse Ordnerinhalte (z. B. Cache über FTP) löschen, nachdem man was umgestellt oder aktualisiert hatte.

Zitat:

---

Zitat von dereo

VNur der Vollständigkeit halber: Mit Cookies der Domain meinst du was genau? Die allgemeinen Cookies im Browser oder gibts im Manager bzw. in Contao 4 noch separate Cookies, die manuell zu löschen sind?

---

Du musst nicht alle Cookies in deinem Browser löschen. Über die Developer Tools des Browsers kannst du auch dediziert nur die Cookies der jeweiligen Domain löschen. Dann musst dich nicht überall dann nochmal neu einloggen ;)

Also htaccess hab ich gelöscht und dann über den Manager aktualisiert, aber es hat sich nichts geändert :eek:

Browser Cache und Cookies der Domain gelöscht?

Zitat:

---

Zitat von Spooky

Browser Cache und Cookies der Domain gelöscht?

---

Ja, alles gelöscht, sogar BleachBit drüber gelassen, damit ALLE Cookies und Websitedaten weg sind. Hab eh nicht so viel, wo ich ständig angemeldet wäre ... Ich seh wahrscheinlich momentan den Wald vor lauter Bäumen nicht. Im Prinzip funktioniert das Frontend problemlos, auch die Adresse zum Backend mit /contao lässt sich problemlos aufrufen, nur nach dem Bestätigen der Anmeldung kommt wieder die alte Fehlermeldung.

Zitat:

---

Zitat von dereo

Habe leider erst nach Fertigstellung der Seite https hinzugefügt und daher die Weiterleitung nach /web, wo ja hininstalliert wird, aufgehoben, damit die Validierungsdatei im Root-Verzeichnis gefunden werden kann.

---

Welche Validierungsdatei? Ist das ein externes SSL-Zertifikat? Ein Let's Encrypt Zertifikat einzurichten, sollte eigentlich recht unkompliziert vonstatten gehen, ohne dass der DocumentRoot geändert werden muss.

Die .htaccess sollte (standardmäßig) so ausschauen:

Code:

---

<IfModule mod_rewrite.c>
    RewriteEngine On

    <IfModule mod_headers.c>
        # Assets in /assets and /bundles either contain a hash in their filename
        # or are called with a ?version suffix, therefore cache them for 1 year.
        RewriteRule ^(assets|bundles)/ - [ENV=CONTAO_ASSETS:true]
        Header set Cache-Control "max-age=31536000" env=CONTAO_ASSETS

        # Allow CORS on the Contao TinyMCE skin.
        RewriteRule ^assets/tinymce4/js/skins/contao/fonts/ - [ENV=CONTAO_TINYMCE_SKIN:true]
        Header set Access-Control-Allow-Origin "*" env=CONTAO_TINYMCE_SKIN
    </IfModule>

    # Determine the RewriteBase automatically and set it as environment variable.
    # If you are using Apache aliases to do mass virtual hosting or installed the
    # project in a subdirectory, the base path will be prepended to allow proper
    # resolution of the index.php file and to redirect to the correct URI. It will
    # work in environments without path prefix as well, providing a safe, one-size
    # fits all solution. But as you do not need it in this case, you can comment
    # the following 2 lines to eliminate the overhead.
    RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$
    RewriteRule ^(.*) - [E=BASE:%1]

    # Sets the HTTP_AUTHORIZATION header removed by Apache
    RewriteCond %{HTTP:Authorization} .
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect to URI without front controller to prevent duplicate content
    # (with and without `/index.php`). Only do this redirect on the initial
    # rewrite by Apache and not on subsequent cycles. Otherwise we would get an
    # endless redirect loop (request -> rewrite to front controller ->
    # redirect -> request -> ...).
    # So in case you get a "too many redirects" error or you always get redirected
    # to the start page because your Apache does not expose the REDIRECT_STATUS
    # environment variable, you have 2 choices:
    # - disable this feature by commenting the following 2 lines or
    # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the
    #  following RewriteCond (best solution)
    RewriteCond %{ENV:REDIRECT_STATUS} ^$
    RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L]

    # If the requested filename exists, simply serve it.
    # We only want to let Apache serve files and not directories.
    RewriteCond %{REQUEST_FILENAME} -f
    RewriteRule ^ - [L]

    # Rewrite all other queries to the front controller.
    RewriteRule ^ %{ENV:BASE}/index.php [L]
</IfModule>

<IfModule !mod_rewrite.c>
    <IfModule mod_alias.c>
        # When mod_rewrite is not available, we instruct a temporary redirect of
        # the start page to the front controller explicitly so that the website
        # and the generated links can still be used.
        RedirectMatch 302 ^/$ /index.php/
        # RedirectTemp cannot be used instead
    </IfModule>
</IfModule>

---

Zitat:

---

Im Prinzip funktioniert das Frontend problemlos, auch die Adresse zum Backend mit /contao lässt sich problemlos aufrufen, nur nach dem Bestätigen der Anmeldung kommt wieder die alte Fehlermeldung.

---

Hast Du in den Einstellung vom "Startpunkt einer Webseite" die Option "HTTPS verwenden" aktiviert?

Leider nein, da ich mich nicht mehr ins Backend einloggen kann seit der Änderung des Pfades. Ich kann die Anmeldemaske aufrufen, aber dann ist Ende. Witzig finde ich allerdings, dass ich den Manager auch problemlos aufrufen kann, mich da anmelden und alles grüne Haken hat, also laut Manager funktioniert alles problemlos. Spooky hat auch auf die Einstellungen geschaut und gesagt, dass er nichts Abnormales finden kann.

Ja, es handelt sich um externe SSL-Zertifikate, da ich bei INTERSSL noch einiges an Guthaben rumliegen hatte, das ich nutzen wollte. Bei meiner eigenen Seite und zwei anderen hats auch problemlos geklappt, aber durch die Installation bzw. den Verweis auf /web bei der Installation von Contao hats dieses Mal leider nicht geklappt. Und die besagte Datei, die von Sectigo überprüft wird, muss eben in der obersten Ebene liegen, daher hab ich den Pfad geändert, in dem Glauben, dass ich das dann wieder problemlos zurückändern kann, nachdem die Datei validiert wurde.

Laut mir hättest Du den DocumentRoot nicht ändern müssen, die Validierung hätte vermutlich auch mit DocumentRoot im web/ Unterordner funktioniert.

Browsercache und Cookies der Domain hast Du ja gelöscht, richtig? Oder es mit einem anderen Browser getestet? Hast Du var/cache/ auch gelöscht?

Zitat:

---

Zitat von xchs

Laut mir hättest Du den DocumentRoot nicht ändern müssen, die Validierung hätte vermutlich auch mit DocumentRoot im web/ Unterordner funktioniert.

Browsercache und Cookies der Domain hast Du ja gelöscht, richtig? Oder es mit einem anderen Browser getestet? Hast Du var/cache/ auch gelöscht?

---

Mit Let's Encrypt wärs im Nachhinein betrachtet vermutlich einfacher gegangen, aber mit der erwähnten zu hinterlegenden .txt-Datei nicht. Habs ausprobiert über die URL, da kam immer eine Fehlermeldung über Contao, dass die Seite nicht existiert, also hab ichs in die oberste „Etage“ verschoben und voila, da ließ sich die gewünschte Datei aufrufen. Ich hätte auch eine andere Art der Validierung wählen können, aber ich dachte ja nicht, dass das so ausufern würde. Für alle weiteren Male bin ich zumindest gewarnt.

Var/chache hab ich manuell nicht geleert, aber da ich komische Symlinks in /web bzw. /web/files hab, nehm ich an, dass die unendliche Weiterleitung sowieso nicht mehr zu beheben ist. Ich werds aber morgen noch einmal probieren. Danke jedenfalls für die Hinweise!