wake-up-neo.net

Fehler im Ausnahmehandler. - Laravel

Es ist eine Laravel-Installationsfrage. Ich habe ein öffentliches Unix-Server-Setup:

<VirtualHost *:80>
ServerAdmin [email protected]
DocumentRoot "/var/www/mydomain"
ServerName mydomain.org
ServerAlias www.mydomain.org
ErrorLog "/var/log/mydomain.org-error_log"
CustomLog "/var/log/mydomain.org-access_log" common
</VirtualHost>

Ich kann Dokumente gut aus/var/www/mydomain liefern, d. H. http://mydomain.org/test.php mit test.php, die Folgendes enthält:

<?php echo 'test';

funktioniert gut.

In Bash, mit Laravel durch Composer installiert und die Dateien betrachten:

# ls /var/www/mydomain/my-laravel-project

.gitattributes  CONTRIBUTING.md artisan         composer.json   phpunit.xml readme.md       vendor
.gitignore      app             bootstrap       composer.lock   public          server.php

Wenn ich also browse:

http://mydomain.org/my-laravel-project/public/

warum berichtet meine Bewerbung:

Error in exception handler.

im Browser - auf einem leeren weißen Bildschirm? Ich erwarte, den Laravel-Startbildschirm zu sehen.

Darüber hinaus zeigen die Protokolldateien auch nichts.

apachelaravel
114
cookie

Die sicherere Option wäre, die Gruppe der Speicherverzeichnisse in Ihre Webservergruppe zu ändern (normalerweise Apache oder www-data, dies kann jedoch zwischen den verschiedenen Betriebssystemen variieren) und die Berechtigungen für das Verzeichnis als 775 beibehalten.

chgrp -R www-data app/storage

Oder mit chown.

chown -R :www-data app/storage

Stellen Sie dann sicher, dass die Verzeichnisberechtigungen 775 sind.

chmod -R 775 app/storage

Von der Laravel-Website : 

Für Laravel muss möglicherweise ein Satz von Berechtigungen konfiguriert werden: Ordner Innerhalb der App/des Speichers ist ein Schreibzugriff des Webservers erforderlich.

244
Jason Lewis

Laravel 5.2

chmod -R 777 Lagerung

Ältere Laravel Chmod 777 app/storage/*

Wenn Sie einen dedizierten Server ohne Benutzerkonten außer Ihrem eigenen eingerichtet haben, sollte 777 kein größeres Sicherheitsrisiko darstellen als alles andere. Es müsste eine andere Schwachstelle für einen böswilligen Benutzer geben, um davon Gebrauch zu machen, und zu diesem Zeitpunkt ist die Erlaubnis für 777 wahrscheinlich ohnehin irrelevant. Wenn Sie sich jedoch auf einem gemeinsam genutzten Server mit anderen Benutzern befinden, denen Sie nicht vertrauen, müssen Sie die komplizierteren Berechtigungen prüfen oder prüfen, ob Ihr Hosting-Provider bereits Isolation bereitgestellt hat.

Sie sollten dies in den Schnellstartdokumenten enthalten und Beispiele für verschiedene Setups bereitstellen. Möglicherweise müssen Sie es auch nach dem ersten Laden erneut ausführen, da automatisch weitere Verzeichnisse erstellt werden. Suchen Sie in Ihren Protokollen nach Schreibfehler.

Ihr DocumentRoot sollte auch/path/to/laravel-project/public sein

18
malhal

Ich habe alte Sitzungen im app/storage/sessions-Ordner gelöscht und 775 die Erlaubnis erteilt, app/storage danach zu funktionieren, wie ein Feuer!

chmod -R 775 app/storage

Viel Glück!

2
Abdulaziz Noor

Der Zug hat das schon vor langer Zeit weitergegeben, aber ich habe noch einen weiteren Rat bezüglich "Fehler in Ausnahmebehandlung".

Ich habe das mit mir gemacht, als ich "php artisan" lief, was eine gute Möglichkeit ist, um festzustellen, ob Ihre Umgebung im Allgemeinen funktioniert. 

Ich habe es ausgeführt und es gab mir diesen Fehler, und ich konnte das Problem nicht ermitteln, bis ich die Handwerkerdatei im Stammverzeichnis des Projekts bearbeitet und eine try catch-Anweisung hinzugefügt hatte: 

try {
    $artisan = Illuminate\Console\Application::start($app);
}
catch (Exception $e)
{
    dd($e->getMessage());
}

An diesem Punkt sah ich endlich eine erleuchtende Botschaft:

string(41) "Connection refused [tcp://127.0.0.1:6379]"

was in meinem Fall eine schlechte Redis-Konfiguration war, könnte aber in Ihrem Fall alles sein. 

Ich hoffe, das hilft jemandem, oder zumindest wenn ich das nächste Mal hier bin, werde ich meine eigene Antwort finden.

1
NiRR

Der kürzeste Weg, um dieses Problem zu lösen, ist der Beginn des Handwerkers mit Sudo. Dies gibt dem Kunsthandwerker alle erforderlichen Berechtigungen und führt auch zu keinen Sicherheitsmängeln.

starten Sie den Handwerker stattdessen mit:

$ php artisan serve

versuchen Sie es mit:

$ Sudo php artisan serve

sie müssen also keine Berechtigungsänderungen vornehmen

0
Skeletor