Startseite
  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche
Startseite › Forum › Drupalcenter.de › Allgemeines zu Drupal ›

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

Eingetragen von McAldo (78)
am 18.04.2020 - 18:00 Uhr in
  • Allgemeines zu Drupal
  • Drupal 8.x

Ich habe eine Drupal 8.8,x Installation und versuche mittels "Aktualisieren" über das Webinterface Module zu aktualisieren. Das scheitert dann am Aufruf der "authorize.php". Ich habe mich als Nutzer mit vollen administrativen Berechtigungen eingeloggt. In den Protokollnachrichten steht dann aber "Gast (nicht überprüft)". Irgendwo auf dem Web von "Diese Aktualisierung herunterladen" über "Weiter" (mit Umschalten in den Wartungsmodus) hin zur URL "https://www.meinewebseite.tdl/core/authorize.php?batch=1&id=369&op=start" wird auf Guest umgeschaltet. Als Meldung bekomme ich dann:

Zugriff verweigert
Sie sind nicht berechtigt, auf diese Seite zuzugreifen.

Theme ist Mayo 8.x-1.3.
Wo in der Drupal-Konfiguration ist da etwas verstellt?

Ich habe eine andere Drupalseite mit der selben Version und auch so konfiguriert, aber aktueller eingerichtet. Da funktioniert alles. Durch Vergleichen der Inhalte auf den Servern habe ich aber nichts gefunden, was dieses Verhalten auslöst. Ich hoffe, hier bekomme ich einen entscheidenden Hinweis.

‹ Warning: "continue" targeting switch is equivalent to "break Modulupdate per Webinterace scheitert an authorize.php und access denied für Admin-User ›
  • Anmelden oder Registrieren um Kommentare zu schreiben

Funktioniert es denn mit dem

Eingetragen von zwerg (736)
am 31.05.2020 - 23:15 Uhr

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

Web: Halle im Bild | n8aktiv
Social: Facebook | Xing

  • Anmelden oder Registrieren um Kommentare zu schreiben

Rückfrage

Eingetragen von McAldo (78)
am 11.06.2020 - 09:42 Uhr
zwerg schrieb

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.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ich meine den Superuser, also

Eingetragen von zwerg (736)
am 11.06.2020 - 10:27 Uhr

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?

Web: Halle im Bild | n8aktiv
Social: Facebook | Xing

  • Anmelden oder Registrieren um Kommentare zu schreiben

Frage

Eingetragen von McAldo (78)
am 11.06.2020 - 10:44 Uhr

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:

access denied         11.06.2020 - 11:40     authorize.php       Gast (nicht überprüft)

Ich hatte mich aber als der Admin-User eingeloggt.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Fehler weiter eingegrenzt

Eingetragen von McAldo (78)
am 20.01.2021 - 11:55 Uhr

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:

if (isset($GLOBALS['request']) and '/.sub-www/index.php' === $GLOBALS['request']->server->get('SC
RIPT_NAME')) {
  $GLOBALS['request']->server->set('SCRIPT_NAME', '/index.php');
}

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:

Zitat:

Zugriff verweigert
Sie sind nicht berechtigt, auf diese Seite zuzugreifen.

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?

  • Anmelden oder Registrieren um Kommentare zu schreiben

Links

Eingetragen von McAldo (78)
am 23.01.2021 - 17:10 Uhr

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/

  • Anmelden oder Registrieren um Kommentare zu schreiben

settings.php

Eingetragen von McAldo (78)
am 23.01.2021 - 17:36 Uhr

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

RewriteBase /.sub-www

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

Und auch bei der update.php:

Zitat:

In order to run update.php you need to either have "Administer software updates" permission or have set $settings['update_free_access'] in your settings.php.

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

  • Anmelden oder Registrieren um Kommentare zu schreiben

Problemeingrenzung

Eingetragen von McAldo (78)
am 26.01.2021 - 10:25 Uhr

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.

cat .htaccess
AddType application/x-httpd-php74 .php

RewriteCond %{HTTP_HOST} ^(www.|)domain1.de$ [OR]
RewriteCond %{HTTP_HOST} ^(www.|)domain2.de$ [OR]
RewriteCond %{HTTP_HOST} ^(www.|)domain3.de$
RewriteRule ^ https://www.domain.de%{REQUEST_URI} [R=301,L]

RewriteCond %{HTTP_HOST} ^(www.|)domain.de$
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://www.domain.de/$1 [R,L]

RewriteCond %{HTTP_HOST} ^www.domain.de [OR]
RewriteCond %{HTTP_HOST} ^domain.de
RewriteCond %{REQUEST_URI} !^/.sub-www/ [NC]
RewriteRule ^(.*)$ /.sub-www/$1

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:

Zitat:

Zugriff verweigert
Sie sind nicht berechtigt, auf diese Seite zuzugreifen.

Und bei update.php:

Zitat:

In order to run update.php you need to either have "Administer software updates" permission or have set $settings['update_free_access'] in your settings.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:

if (isset($GLOBALS['request']) and '/.sub-www/index.php' === $GLOBALS['request']->server->get('SCRIPT_NAME')) {
  $GLOBALS['request']->server->set('SCRIPT_NAME', '/index.php');
}

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?

  • Anmelden oder Registrieren um Kommentare zu schreiben

Wenn der Provider keine freie

Eingetragen von wla (9016)
am 26.01.2021 - 11:40 Uhr

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.

.
Werner
drupal-in-duesseldorf.de
Moderator und Drupal Trainer
* - - - - - - - - - - - - - - - - - - - - - - - - - - - *

  • Anmelden oder Registrieren um Kommentare zu schreiben

Ich hatte gehofft, bis auf

Eingetragen von McAldo (78)
am 26.01.2021 - 11:52 Uhr

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. :-)

  • Anmelden oder Registrieren um Kommentare zu schreiben

Auch,wenn es noch über

Eingetragen von montviso (1886)
am 27.01.2021 - 08:43 Uhr

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.

LG Regina Oswald
-------------------------
Montviso - Internetdienstleistungen
http://www.montviso.de

  • Anmelden oder Registrieren um Kommentare zu schreiben

Benutzeranmeldung

  • Registrieren
  • Neues Passwort anfordern

Aktive Forenthemen

  • [gelöst]Pflichtfeld vom User deaktivieren lassen
  • Konto löschen, wie? (Drupalorg/Drupalcenter)
  • Layout-Builder hängt
  • Drupal 8/9 SEO-Beratung/Coaching
  • Verschachtelte UND / ODER Abfrage mit hook_views_query_alter
  • Kartenansicht, Position des Users und Nodes anzeigen
  • Hilfe zu Views und Filter?
  • Views für 2 Kategorien
  • [gelöst]Probleme nach löschen eines Menüpunktes im Adminmenü
  • [gelöst]Zufallsausgabe von Inhalt
  • Variable aus dem inkludierten Partial Template auslesen
  • Probleme beim Versand von Mails via Drupal 9
Weiter

Neue Kommentare

  • Danke das ist die Lösung
    vor 2 Stunden 48 Minuten
  • Ah, das sind wertvolle Hinweise
    vor 5 Stunden 49 Minuten
  • Schau Dir mal folgenden
    vor 6 Stunden 2 Minuten
  • Du kannst die Eigenschaften
    vor 6 Stunden 6 Minuten
  • Bitte meinen Account auch löschen
    vor 6 Stunden 6 Minuten
  • Danke, den hook kannte ich natürlich
    vor 7 Stunden 36 Minuten
  • Ich würde das mit
    vor 9 Stunden 13 Minuten
  • php war es nicht
    vor 21 Stunden 35 Minuten
  • Ich mache so Sachen:-)
    vor 23 Stunden 41 Minuten
  • Bei Google musst Du erst ab
    vor 2 Tagen 10 Stunden

Statistik

Beiträge im Forum: 246097
Registrierte User: 18884

Neue User:

  • Stine_64
  • uniquename
  • xapizm

» Alle User anzeigen

User nach Punkten sortiert:
wla9016
stBorchert6003
quiptime4972
Tobias Bähr4019
bv3917
ronald3832
md3717
Thoor3678
Alexander Langer3416
Exterior2903
» User nach Punkten
Zur Zeit sind 0 User und 5 Gäste online.

Hauptmenü

  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche

Quicklinks I

  • Infos
  • Drupal Showcase
  • Installation
  • Update
  • Forum
  • Team
  • Verhaltensregeln

Quicklinks II

  • Drupal Jobs
  • FAQ
  • Drupal-Kochbuch
  • Best Practice - Drupal Sites - Guidelines
  • Drupal How To's

Quicklinks III

  • Tipps & Tricks
  • Drupal Theme System
  • Theme Handbuch
  • Leitfaden zur Entwicklung von Modulen

RSS & Twitter

  • Drupal Planet deutsch
  • RSS Feed News
  • RSS Feed Planet
  • Twitter Drupalcenter
Drupalcenter Team | Impressum & Datenschutz | Kontakt
Angetrieben von Drupal | Drupal is a registered trademark of Dries Buytaert.
Drupal Initiative - Drupal Association