Access denied Fehler nach Upload auf Testserver von Lokal

Deutsches Forum
1

Hallo,

und zwar habe ich einen neuen OXID-Shop v6.4.2 per ddev bei mir lokal installiert. Der Shop läuft und ich habe lokal damit keine Probleme.

Nun habe ich alle Dateien auf einen Testserver mit php7.4 kopiert. Die config.inc.php entsprechend angepasst. Jedoch erhalte ich hier eine komplett weiße Seite mit “Access denied”.

Ich habe bisher nur mit dem OXID-Shop Version 4 gearbeitet und weiß daher jetzt nicht, wo genau es Zugriffsprobleme geben könnte. Daher meine Frage an euch, ob dieser Fehler insofern bekannt ist, um in gewissen Richtung zu schauen? Sprich, wo sollte ich mal prüfen, wo etwas nicht passt?

Bin über jede Hilfe/Tipp dankbar.

2

Moin @O-Schumiel :slight_smile:

hast Du den das Document-Root (Zielverzeichnis) auf source Verzeichnis gesetzt?

Viele Grüße,
Tim

3

Du meinst $this->sShopDir? Wenn ja, das habe ich auf den “/source”-Ordner gelegt. Einfach den Pfad davor angepasst.

Ich habe den apache DocRoot auch auf den source-Ordner gelegt. Dabei dachte ich, dass der Shop dann vielleicht nicht auf “var” und “vendor” zugreifen kann. Aber hier habe den DocRoot dann eine Ebene hoch gesetzt und habe die URL “domain.de/source” aufgerufen, aber trotzdem der gleiche Fehler.

4

Nein.

Sehr gut.

Nein, dies würde ich ausschließen.

Du nutzt aber schon eine Community Edition?

Es gibt fürs Frontend ein err_accessdenied.tpl Template was aber anscheinend nur für eine Enterprise Edition zum Einsatz kommt und bei fehlenden Rechten die Fehlermeldung “Access denied” wirft.

Bin dort nämlich über einen Pull-Request gestoßen, dass dieses Template im Flow Theme für Enterprise Edition gefehlt hatte 0006643: Template err_accessdenied.tpl is missing - OXID eShop bugtrack

Kommst Du den in den Admin?

ps. Die Überschrift verwirrt, besser würde passen “Access denied Fehler nach Upload auf Testserver von Lokal”

5

Ja, ich benutze die Community Edition.

Nein. Ich komme nicht auf den admin. Egal welche URL ich aufrufe, ich erhalte nur Access denied.

6

Okay, dann können wir meine Annahme mit Enterprise Edition ausschließen.

Surfst Du über ein VPN? Oder nutzt Du bei Dir einen Proxy zum Surfen?

Weitere Hintergründe "Access Denied" Internetseite wird nicht geladen | ComputerBase Forum

7

Sorry, diese Aussage stimmte nicht ganz. Wenn ich die offline.html und robots.txt aufrufe, dann erhalte ich für diese Seiten eine Ausgabe.

8

Ah okay, hast du auch an Deine Datenbank gedacht?
Eine Datenbank auf Deinem Testserver anzulegen. Die Daten von Lokal zu übertragen bzw. zu importieren (ohne View Tabellen am besten).

9

Kannst du überhaupt irgendein PHP Script aufrufen? z.b. einfach mal test.php mit:

<?php
phpinfo()

Und du schreibst nicht, ob du auch die Datenbank umgezogen hast.

10

Die Datenbank habe ich übertragen. Sorry, muss ich erwähnen, stimmt. War mir aber zu klar, dass man die DB übertragen muss und dachte, muss man nicht erwähnen. :wink:

Der Hinweis von naledre hat neue Erkenntnisse gebracht. Ich kann keine php-Dateien aufrufen. txt, html, usw. funktionieren. Das bedeutet doch, dass am PHP (apache) etwas kaputt ist oder?

11

Dies könnte bedeuten, dass kein PHP installiert oder Dir Rechte fehlen PHP Skripte auszuführen. Am besten fragst bei Deinem Hoster wo die Testinstallation jetzt liegt nach.

12

Ja, daran lag es am Ende auch. Oh man. Ich danke euch.

Letzte Frage: Nun erhalte ich folgende Meldung:

Maintenance mode, please try again later.
[Click here to reload shop.]

Wartungsarbeiten, bitte versuchen Sie es später noch einmal.
[Klicken Sie hier, um den Shop erneut zu laden.]

Auch wenn ich /admin aufrufe.

13

Gerne. Dies der Klassiker. Du hast die View Tabellen mit importiert.

Dafür musst in der config.inc.php die Broken Views deaktivieren indem die Variable

// Enable temporarily in case you can't access the backend due to broken views
$this->blSkipViewUsage = false;

auf true setzt. Dich in Admin einloggst, den Datenbank-Views neu generieren Button bestätigst und anschließend wieder zurück auf false setzen.

Dabei die Rechte von der config.inc.php nach Bearbeitung wieder auf 444 Modus setzen.

14

Ich habe es auf true gesetzt. Jedoch erhalte ich weiterhin diese Meldung. Frontend und Admin.

Ich habe dann die View-Tabellen gelöscht. Weiterhin die Meldung. Frontend und Admin.

Danach habe ich alle Tabellen gelöscht und nochmal ohne die View-Tabellen importiert. Weiterhin erhalte ich diese Meldung. Frontend und Admin.

Die Datenbank ist, wie lokal auch, eine MariaDB 10.1 mit Zeichencodierung utf8_general_ci. Alle Tabellen auch auf utf8_general_ci.

In den OXID- und apache-Logs steht nichts drin.

Das Skript biegt in der bootstrap.php in die Funktion oxTriggerOfflinePageDisplay() (Zeile 217) ab. Lokal tut sie das nicht.

15

ist ein eintrag vorhanden in oxshops? mit der OXID 1?

16

Ja. Auch die Spalte OXACTIVE hat eine 1. OXURL auch entsprechend angepasst. /source/tmp/-Ordner geleert. Auch ohne Erfolg.

Edit: Hm. Kein Datenbankzugriff. :frowning: Das löse ich erstmal. — Auch das ändert nichts.

17

Es läuft. Vielen Dank für jeden einzelnen Tipp.

Nachdem die DB dann wirklich zugreifbar, muss ich $this->blSkipViewUsage = false; noch auf true setzen. Was ich aber nicht verstehe, weil ich die View-Tabellen nicht mit importiert habe. Zumindestens hatte ich nach View-Tabellen im OXID gegoogelt und die alle nicht importiert. Egal. So komme ich weiter. Danke!!

1 Like
18

Wenn sie nicht da sind, können sie nicht genutzt werden. Deswegen true. Schreib die Views im Admin / Service neu.

19

Abgefahren :nerd_face:

20

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.