Modulupdate per Webinterace scheitert an authorize.php und access denied für Admin-User

Funktioniert es denn mit dem reinen Admin-Konto? Es gibt bspw. diesen Issue, wonach lokale Cookies die Authorisierung blockieren.

Was meinst du mit "reinem Admin-Konto" Ich mache das mit dem bei der Installation angegebenen ersten Nutzer. Dieser ist in den Rollen "Angemeldeter Benutzer" und "Administrator". Es funktionieren per Webinterface alle administrativen Funktionen. Also z.B. neue Benutzer anlegen, neu Inhalte hinzufügen, alles was man unterhalb von "Struktur" machen kann. Alles, bis auf die Updates oder Installation von Modulen per Webinterface.

Danke für den Link. Das hat leider auch nicht geholfen. Ich bin ratlos.

Ich meine den Superuser, also den mit der UID = 1. Der braucht keine Rollen, weil er eh alles darf. Hast du mal die Drupal-Logfiles und die Server-Logs geprüft? Was genau willst du aktualisieren?

Ok, ich dachte, ich bin "superuser" mit meinem Account, den ich bei der Erstinstallation erstellt habe. Wie finde ich den "superuser".

Ich möchte die Module per Webinterface aktualisieren, also nicht per SFTP oder SCP auf den Server kopieren. Dabei kommt dann immer die Fehlermeldung siehe oben.

Im Bereich "Aktuelle Protokollnachrichten" steht:

Ich hatte mich aber als der Admin-User eingeloggt.

Das Problem kommt daher, dass der Webhoster das Verzeichnis htdocs/ als DocumentRoot für den Webserver eingerichtet hat, bzw. alle Anfragen an www.example.foo in dieses Verzeichnis gesendet werden.

Da ich noch eine andere Subdomain für Testkonfigurationen nutze habe in ich dem Verzeichnis diese Ordner:

.sub-test/ (URL https://test.example.foo)
.sub-www/ (URL https://www.example.foo)

Bei dem Hoster werden URLs an den jeweiligen .sub- Ordner geleitet, außer eben bei www. Dafür gibt es dann eine .htaccess mit entsprechende ReWrite Rules um das an .sub-www zu leiten.

Damit Weiterleitungen innerhalb von www auch funktionieren, habe ich diese Zeilen in der settings.php eingetragen:

Und nach vielem hin und her mit Ausschlussverfahren denke ich, es ist irgendwas bei diesem code noch nicht ganz richtig, so dass ich beim installieren eines Modul über die Weboberfläche oder beim Aufruf von "update.php" diese Meldung bekomme:

Ich bin da wie geschrieben als User 1 eingeloggt, also volle Admin-Berechtigungen. Hat jemand eine Idee, was in dem benötigten Code anders sein muss?

Offenbar liegt das Problem in Drupal. Der Hoster hat die Domain mit allen Daten dupliziert und dadurch de Zugriff ändern können. Es passiert trotzdem.

Habe nun das gefunden:
- https://stackoverflow.com/questions/60789100/drupal-install-module-acces...
https://www.drupal.org/project/drupal/issues/2764541#comment-13517707
- https://bobcares.com/blog/drupal-admin-access-denied/

Die Drupalinstallation ist im Verzeichnis .sub-www/, habe also in der settings.php das mal bei RewriteBase eingetragen

Brachte aber auch keinen Erfolg. Immer noch Access denied beim Installieren von zusätzlichen Modulen.

Und auch bei der update.php:

Ich bin, wie gesagt, als User 1 eingeloggt. Dieser sollte auf alles volle Berechtigung haben?

Und wieder ein Stück weiter. Vielleicht hat ja mal jemand anderes auch so eine "Herausforderung". :-)

Ich fasse die Konfiguration und das Fehlerbild noch einmal zusammen:

Der Webserver ist von Seiten des Hosters so eingerichtet, dass Anfragen an 'www' in das Verzeichnis htdocs/ geleitet werden. Liegt da drin z.B. eine Datei index.html, wird diese aufgerufen.
Legt man sich eine neu Subdomain an, z.B. neu.domain.de (statt www.domain.de), wird dazu das Verzeichnis htdocs/.sub-neu/ erstellt. Alle Anfragen an neu.domain.de landen dann in diesem Verzeichnis.

Möchte man nun auch www in einem Subverzeichnis haben, um die Verzeichnisstruktur etwas aufgeräumter zu haben, legt man sich einen entsprechenden Unterordner an. Dieser kann htdocs/irgendwas sein, aber auch htdocs/.sub-www. Anfragen landen nun aber nicht direkt da drin, sondern müssen mittels Rules in einer htdocs/.htaccess dahin geleitet werden.

Diese Rules sehen wie nachfolgend aus. Es werden hier auch noch 3 andere Alias-Domains auf die Hauptdomains umgeleitet. Die Weiterleitungen funktionieren auch alle. Sowohl mit auch als ohne die Alias-Domains.

Damit funktioniert die Drupal-Webseite und kann per www.domain.de angesprochen werden.

ABER

Es funktioniert NICHT:

• update.php
• Installation von Modulen per Webinterface

Es kommen dann die Fehler die man auf den oben verlinkten Seiten schon genannt werden.

Beim Installationsversuch:

Und bei update.php:

WICHTIG! Ich bin bei all diesen Aktionen als "User 1" eingeloggt. Ich habe den Cache gelöscht und auch den Browser geschlossen, bzw. jedes mal ein neues privates Fenster im Firefox gestartet. Auch befindet sich am Ende der Datei sites/default/settings.php diese Zeilen:

Ich bin all die Schritte durchgegangen, die man auf den Seiten findet, bei denen das Fehlerbild geschildert wird.

Ich habe nun also mal ein komplettes Backup dieser Seite (Daten in htdocs/.sub-www sowie Dump der MySQL-Datenbank) bei einem anderen Hoster importiert. Bei diesem kann man per Webinterface einstellen, dass Anfragen per www.domain.de oder domain.de direkt im gewünschten Verzeichnis landen. Das Ergebnis ist, es funktioniert alles, wie man es gewöhnt ist. Die Installation von Modulen oder auch update.php.

Ich schließe nun daraus, dass der Fehler in den Umleitungen in der Datei htdocs/.htaccess liegt.
Sicher war es einmal eine gute Idee, per Default Anfragen an www direkt nach htdocs/ zu lenken und wenn man ein Unterverzeichnis für www möchte, das per htaccess zu lösen. Hier scheint es aber nicht mehr zeitgemäß und eher hinderlich zu sein.

Die Frage ist nun, bekommt man die Umleitungen in htdocs/.htaccess so eingestellt, dass Drupal nicht die Information verliert, dass ich als "User 1" eingeloggt bin? Oder ist da vielleicht doch ein Fehler in Drupal, dass diese Webserverkonfiguration nicht richtig funktioniert?

Wenn der Provider keine freie Wahl des DocumentRoor zuläßt, also des Verzeichnisses mit der index.php, solltest Du ihn wechseln. Das gilt sowohl für die Hauptdomain als auch für Subdomains!
Daneben braucht es für Drupal 8 und aufwärts immer einen SSH-Zugang zur Seite.
Eine Drupal 8/9 Seite sollte mit composer aufgebaut werden, das gilt auch für das Installieren und Updaten von Modulen. Manche Module lassen sich heute nur noch über composer installieren. Wenn Du die Seite nach Anleitung mit composer aufbaust, ergibt sich eine veränderte Struktur der Seite. Das Installationsverzeichnis bekommt ein Unterverzeichnis "web", in dem Drupal liegt und auch die index.php. Auch deshalb ist es wichtig, das DocumentRoot frei wählen zu können, hier das "web" Unterverzeichnis.
Wenn Du wegen zu geringer php-Memory-Ausstattung den composer beim Provider nicht einsetzen kannst, geht das auch über eine lokale Installation mit composer, die Du anschließend mit tar oder zip einpackst, den komprimierten File zum Server hochlädst und dort entpackst. Das erfordert Arbeit in einer Shell-Umgebung, sowohl lokal als auch beim Provider. Daran muß man sich erst einmal gewöhnen. Jede andere Arbeitsweise wird Dich immer wieder vor Probleme stellen, die andere Leute nicht haben. Das Arbeiten mit composer ist heute die bei Drupal empfohlene Methode. Du solltest Deine Arbeitsweise darauf umstellen.

Ich hatte gehofft, bis auf die Updates von core alles per Webinterface machen zu können, damit ich mal andere anlernen kann auch mal ein Modul zu installieren.
Wenn der Weg über Composer ist, wozu gibt es dann die Möglichkeit Module per Webinterface zu installieren oder zu updaten?

Ich nutze den SSH-Zugang aktuell für diese Zwecke um mit drush update das DB-Update zu machen, weil es über Web bei dieser Installation nicht geht wegen der Provider-Einschränkung (es ist in Klärung ob die das geändert bekommen, oder ich eben wechseln werde :-) ).

Für den Zweck und Umfang der Seite ist es tatsächlich einfacher mittels Webinterface. Bei größeren Installationen mit mehr Ansprüchen würde ich dir Recht geben. Und da dann natürlich auch Git hinzuziehen für Versionsverwaltung der config. :-)

Auch,wenn es noch über Webinterface zu installieren oder updaten geht, kann ich ab D8 wirklich nur empfehlen, Composer zu verwenden.
Mit Composer 2 läuft es bei mir bei All-Inkl ganz wunderbar auch auf sharerd Hosting.
Und es ist deutlich entspannter.