web-dev-qa-db-ja.com

例外ハンドラーでエラーが発生しました。 -Laravel

Laravel-installに関連した質問です。私は一般向けのUnixサーバーをセットアップしています。

<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>

Test.phpを含む/ var/www/mydomainからドキュメントを提供できます（つまり、 http://mydomain.org/test.php ）

<?php echo 'test';

正常に動作します。

Bashで、LaravelをComposerを介してインストールし、ファイルを確認します。

# 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

だから私が閲覧するとき：

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

私のアプリケーションが報告する理由：

Error in exception handler.

ブラウザで-空白の白い画面で？ Laravelスプラッシュスクリーンが表示されることを期待しています。

さらに、ログファイルも何も明らかにしません。

apachelaravel
114
cookie

より安全なオプションは、ストレージディレクトリのグループをWebサーバーグループ（通常はApacheまたはwww-dataですが、これはオペレーティングシステムによって異なる場合があります）に変更し、ディレクトリのアクセス許可を775のままにすることです。

chgrp -R www-data app/storage

または、chownを使用します。

chown -R :www-data app/storage

次に、ディレクトリのアクセス許可が775であることを確認します。

chmod -R 775 app/storage

Laravel Webサイト から：

Laravelでは、1セットのアクセス許可を設定する必要があります。アプリ/ストレージ内のフォルダーには、Webサーバーによる書き込みアクセスが必要です。

244
Jason Lewis

Laravel 5.2

chmod -R 777ストレージ

Old Laravel chmod 777 app/storage/*

自分以外のユーザーアカウントを持たない、合理的にロックダウンされた専用サーバーを持っている場合、777は他のものよりもセキュリティリスクを引き起こすべきではないことに注意してください。悪意のあるユーザーがそれを利用するためには、他の脆弱性が必要であり、その時点で、777の許可はおそらくとにかく無意味です。ただし、信頼できない他のユーザーと共有サーバーを使用している場合は、より複雑なアクセス許可を調べるか、ホスティングプロバイダーが既に分離を提供しているかどうかを確認する必要があります。

彼らは本当にこれをクイックスタートドキュメントに入れ、さまざまなセットアップの例を提供するべきです。さらにディレクトリが自動的に作成されるため、最初のロード後に再度実行する必要があります。ログで書き込みエラーを確認します。

また、DocumentRootは/ path/to/laravel-project/publicでなければなりません

18
malhal

app/storage/sessionsフォルダー内の古いセッションを削除し、775にapp/storageの許可を与えた後、それは火事のように動作しています！

chmod -R 775 app/storage

幸運を祈ります！

2
Abdulaziz Noor

バンドワゴンはかなり前にこれを引き継いでいますが、それでも「例外ハンドラーのエラー」に関するアドバイスがあります。

「php artisan」を実行したときにこれが起こっていました。これは、環境が一般的に機能しているかどうかを評価するのに適した方法です。

私はそれを実行しましたが、そのエラーが発生し、プロジェクトのルートディレクトリにある職人のファイルを編集してtry catchステートメントを追加するまで、問題を特定できませんでした。

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

その時点で、私はついに啓発的なメッセージを見ました：

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

私の場合、これは悪いredis構成でしたが、あなたの場合は何でもかまいません。

これが誰かの助けになるか、少なくともここに来たときに自分の答えが見つかることを願っています。

1
NiRR

これを解決する最短の方法は、Sudoで職人を始めることです。これにより、職人に必要なすべての権限が与えられ、セキュリティ上の問題も発生しません。

そのため、代わりに職人サーブを開始します：

$ php artisan serve

使用してみてください：

$ Sudo php artisan serve

したがって、アクセス許可を変更する必要はありません

0
Skeletor