5.6から5.6.30へのアップグレード（セキュリティーリリース）Upgrading To 5.6.30 From 5.6 (Security Release)
Laravel5.6.30はセキュリティーリリースのため、すべてのユーザーに対して即時にアップグレードすることを推奨します。また、Laravel5.6.30はクッキーの暗号化とシリアライズに関するロジックに、互換性がない変更を含んでいるため、アプリケーションのアップグレード時に以降の注釈を注意深く読んでください。Laravel 5.6.30 is a security release of Laravel and is recommended as an immediate upgrade for all users. Laravel 5.6.30 also contains a breaking change to cookie encryption and serialization logic, so please read the following notes carefully when upgrading your application.
この脆弱性はアプリケーションの暗号化キー（APP_KEY環境変数）が悪意のあるユーザーからアクセスされる場合にのみ悪用されます。 通常、アプリケーションのユーザーが、この値にアクセスできる可能性はありません。しかしながら、以前雇用していた人が暗号化キーにアクセスできていた場合、アプリケーションへ攻撃するためにこのキーを利用することができます。悪意のある人々の手に、暗号化キーが渡ったと信じるいかなる理由がある場合はいつでも、キーの値を変更すべきです。This vulnerability may only be exploited if your application encryption key (APP_KEY environment variable) has been accessed by a malicious user. Typically, it is not possible for users of your application to gain access to this value. However, ex-employees that had access to the encryption key may be able to use the key to attack your applications. If you have any reason to believe your encryption key is in the hands of a malicious party, you should always rotate the key to a new value.
クッキーのシリアライズ化Cookie Serialization
**Laravel5.6.30では、クッキー値のシリアライズ化／非シリアライズ化を無効にしました。その理由は、Laravelのすべてのクッキーは、暗号化し、署名してあり、クライアントによる改ざんに対し、通常安全であると考えられます。しかしながら、アプリケーションの暗号化キーが悪意のある人々の手に入れば、彼らは暗号化キーを使用しクッキー値を生成できます。アプリケーションの中の任意のクラスメソッドを呼び出すことなど、PHPオブジェクトのシリアライズ化／非シリアライズ化に本来の脆弱性を悪用できてしまいます。Laravel 5.6.30 disables all serialization / unserialization of cookie values. Since all Laravel cookies are encrypted and signed, cookie values are typically considered safe from client tampering. However, if your application's encryption key is in the hands of a malicious party, that party could craft cookie values using the encryption key and exploit vulnerabilities inherent to PHP object serialization / unserialization, such as calling arbitrary class methods within your application.
すべてのクッキー値に対するシリアライズ化を無効にすることで、アプリケーションのセッションはすべて無効になり、ユーザーはアプリケーションに再ログインする必要が起きます。更に、アプリケーションで使用している他の暗号化クッキーの設定値が、無効になります。このため、カスタムクッキー値がリストと一致する事を確認するロジックをアプリケーションに追加する必要があるかも知れません。そうしない場合、全てを破棄することになります。Disabling serialization on all cookie values will invalidate all of your application's sessions and users will need to log into the application again. In addition, any other encrypted cookies your application is setting will have invalid values. For this reason, you may wish to add additional logic to your application to validate that your custom cookie values match an expected list of values; otherwise, you should discard them.
クッキーのシリアライズ化の設定Configuring Cookie Serialization
アプリケーションの暗号化キーにアクセスできない場合、この脆弱性は悪用できないため、今回の変更に対してもアプリケーションの互換性を維持できるように、暗号化クッキーのシリアライズ化を最有効にする手段を提供します。クッキーのシリアライズ化を有効／無効にするには、App\Http\Middleware\EncryptCookies ミドルウェアのserializeスタティックプロパティを変更してください。Since this vulnerability is not able to be exploited without access to your application's encryption key, we have chosen to provide a way to re-enable encrypted cookie serialization while you make your application compatible with these changes. To enable / disable cookie serialization, you may change the static serialize property of the App\Http\Middleware\EncryptCookies middleware[https://github.com/laravel/laravel/blob/master/app/Http/Middleware/EncryptCookies.php]:
/**
* クッキーをシリアライズするかの指定
*
* @var bool
*/
protected static $serialize = true;
注意 暗号化されたクッキーのシリアライズ化を有効にし、暗号化キーが悪意のある他者からアクセスできる場合、攻撃される可能性のある脆弱性がアプリケーションに起きます。キーが悪意のある人々の手に入ったと確信できる場合は、暗号化されたクッキーのシリアライズを有効にする前に、キーを新しい値に変更すべきです。Note: When encrypted cookie serialization is enabled, your application will be vulnerable to attack if its encryption key is accessed by a malicious party. If you believe your key may be in the hands of a malicious party, you should rotate the key to a new value before enabling encrypted cookie serialization.
Dusk4.0.0Dusk 4.0.0
Dusk4.0.0がリリースされ、クッキーをシリアライズしなくなりました。クッキーのシリアライズを有効にする場合は、Dusk3.0.0を使用し続けてください。そうでなければ、Dusk4.0.0へアップグレードしてください。Dusk 4.0.0 has been released and does not serialize cookies. If you choose to enable cookie serialization, you should continue to use Dusk 3.0.0. Otherwise, you should upgrade to Dusk 4.0.0.
Passport6.0.7Passport 6.0.7
Passport6.0.7が、新しいLaravel\Passport\Passport::withoutCookieSerialization()メソッドと共にリリースされました。クッキーのシリアライズを無効にした場合は、アプリケーションのAppServiceProviderの中で、このメソッドを呼び出す必要があります。Passport 6.0.7 has been released with a new Laravel\Passport\Passport::withoutCookieSerialization() method. Once you have disabled cookie serialization, you should call this method within your application's AppServiceProvider.
5.5から5.6.0へのアップグレードUpgrading To 5.6.0 From 5.5
見積もり時間：１０〜３０分Estimated Upgrade Time: 10 - 30 Minutes
Note: 私達は、互換性を失う可能性がある変更を全部ドキュメントにしようとしています。しかし、変更点のいくつかは、フレームワークの明確ではない部分で行われているため、一部の変更が実際にアプリケーションに影響を与えてしまう可能性があります。{note} We attempt to document every possible breaking change. Since some of these breaking changes are in obscure parts of the framework only a portion of these changes may actually affect your application.
PHPPHP
Laravel5.6の動作には、PHPバージョン7.1.3以上が必要です。Laravel 5.6 requires PHP 7.1.3 or higher.
依存パッケージのアップデートUpdating Dependencies
composer.jsonファイルのlaravel/framework依存指定を5.6.*に、fideloper/proxy依存指定を^4.0へアップデートしてください。Update your laravel/framework dependency to 5.6.* and your fideloper/proxy dependency to ^4.0 in your composer.json file.
さらに、以下のファーストパーティLaravelパッケージを使用している場合は、最新のリリースへアップグレードしてください。In addition, if you are using the following first-party Laravel packages, you should upgrade them to their latest release:
もちろん、アプリケーションで使用しているサードパーティパッケージについても調査し、Laravel5.6をサポートしているバージョンを使用していることを確認してください。Of course, don't forget to examine any 3rd party packages consumed by your application and verify you are using the proper version for Laravel 5.6 support.
Symfony4Symfony 4
Laravelを動作させるために使用している、すべてのSymfonyコンポーネントは、Symfony ^4.0シリーズへアップグレードされました。アプリケーションで直接Symfonyコンポーネントを取り扱っている場合は、Symfonyの変更ログをレビューすべきでしょう。All of the underlying Symfony components used by Laravel have been upgraded to the Symfony ^4.0 release series. If you are directly interacting with Symfony components within your application, you should review the Symfony change log[https://github.com/symfony/symfony/blob/master/UPGRADE-4.0.md].
PHPUnitPHPUnit
アプリケーションのphpunit/phpunit依存指定は、^7.0にアップグレードしてください。You should update the phpunit/phpunit dependency of your application to ^7.0.
配列Arrays
Arr::wrapメソッドThe Arr::wrap Method
Arr::wrapメソッドへnullを渡すと、空の配列が返ってくるようになりました。Passing null to the Arr::wrap method will now return an empty array.
ArtisanArtisan
optimizeコマンドThe optimize Command
以前から非推奨になっていた、optimize Artisanコマンドは削除されました。PHP自身がOPcacheを含んだ、最近の向上により、optimizeコマンドは妥当なパフォーマンスの向上を提供できなくなりました。そのため、composer.jsonファイルのscripts項目から、php artisan optimizeを取り除いてください。The previously deprecated optimize Artisan command has been removed. With recent improvements to PHP itself including the OPcache, the optimize command no longer provides any relevant performance benefit. Therefore, you may remove php artisan optimize from the scripts within your composer.json file.
BladeBlade
HTMLエンティティエンコーディングHTML Entity Encoding
以前のバージョンのLaravelでは、Blade（およびeヘルパ）は、HTMLエンティティをダブルエンコードしませんでした。これは、裏で使用しているhtmlspecialchars関数のデフォルト動作とは異なり、コンテンツのレンダリングやインラインJSONコンテンツをJavaScriptフレームワークへ渡す際に、予想外の動作を引き起こしました。In previous versions of Laravel, Blade (and the e helper) would not double encode HTML entities. This was not the default behavior of the underlying htmlspecialchars function and could lead to unexpected behavior when rendering content or passing in-line JSON content to JavaScript frameworks.
Laravel5.6では、Bladeとeヘルパはデフォルトとして、特別な文字をダブルエンコードします。これにより、裏で動作しているPHPのhtmlspecialchars関数のデフォルトと、この機能は動作が統一されました。ダブルエンコーディングを行わない、以前の振る舞いを継続したい場合は、Blade::withoutDoubleEncodingメソッドを使用します。In Laravel 5.6, Blade and the e helper will double encode special characters by default. This brings these features into alignment with the default behavior of the underlying htmlspecialchars PHP function. If you would like to maintain the previous behavior of preventing double encoding, you may use the Blade::withoutDoubleEncoding method:
<?php
namespace App\Providers;
use Illuminate\Support\Facades\Blade;
use Illuminate\Support\ServiceProvider;
class AppServiceProvider extends ServiceProvider
{
/**
* アプリケーションの全サービスの初期処理
*
* @return void
*/
public function boot()
{
Blade::withoutDoubleEncoding();
}
}
キャッシュCache
レートリミッターのtooManyAttemptsメソッドThe Rate Limiter tooManyAttempts Method
このメソッドの引数から、使用されていなかった$decayMinutes引数が削除されました。このメソッドを自分の実装でオーバーライドしている場合、メソッドからこの引数を削除してください。The unused $decayMinutes parameter was removed from this method's signature. If you were overriding this method with your own implementation, you should also remove the argument from your method's signature.
データベースDatabase
morphsカラムのインデックス順Index Order Of Morph Columns
morphsマイグレーションメソッドにより作られるカラムのインデックスが、効率を改善するために改善されました。マイグレーションでmorphsメソッドを使用している場合は、マイグレーションのdownメッソッドを実行しようと試みると、エラーが発生します。アプリケーションが開発段階の場合は、migrate:freshコマンドを使い、初めからデータベースを構築し直してください。アプリケーションが実働している場合は、明確にmorphsメソッドにインデックス名を渡す必要があります。The indexing of the columns built by the morphs migration method has been reversed for better performance. If you are using the morphs method in one of your migrations, you may receive an error when attempting to run the migration's down method. If the application is still in development, you may use the migrate:fresh command to rebuild the database from scratch. If the application is in production, you should pass an explicit index name to the morphs method.
MigrationRepositoryInterfaceメソッド追加MigrationRepositoryInterface Method Addition
MigrationRepositoryInterfaceへ、新しくgetMigrationsBatchesメソッドが追加されました。このクラスを自分で実装するというのは、まずあり得ませんが、実装している場合は実装にこのメソッドを追加してください。フレームワークのデフォルト実装を例として参照してください。A new getMigrationsBatches method has been added to the MigrationRepositoryInterface. In the very unlikely event that you were defining your own implementation of this class, you should add this method to your implementation. You may view the default implementation in the framework as an example.
EloquentEloquent
getDateFormatメソッドThe getDateFormat Method
getDateFormatメソッドが、protectedの代わりにpublicになりました。This getDateFormat method is now public instead of protected.
ハッシュHashing
新しい設定ファイルNew Configuration File
ハッシュの全設定は、config/hashing.php設定ファイルへ保存されるようになりました。デフォルトの設定ファイルをアプリケーションへコピーしてください。ほとんどの場合、デフォルトドライバーとしてbcryptを継続する必要があります。しかしながら、argonもサポートされました。All hashing configuration is now housed in its own config/hashing.php configuration file. You should place a copy of the default configuration file[https://github.com/laravel/laravel/blob/master/config/hashing.php] in your own application. Most likely, you should maintain the bcrypt driver as your default driver. However, argon is also supported.
ヘルパHelpers
eヘルパThe e Helper
以前のバージョンのLaravelでは、Blade（およびeヘルパ）は、HTMLエンティティをダブルエンコードしませんでした。これは、裏で使用しているhtmlspecialchars関数のデフォルト動作とは異なり、コンテンツのレンダリングやインラインJSONコンテンツをJavaScriptフレームワークへ渡す際に、予想外の動作を引き起こしました。In previous versions of Laravel, Blade (and the e helper) would not double encode HTML entities. This was not the default behavior of the underlying htmlspecialchars function and could lead to unexpected behavior when rendering content or passing in-line JSON content to JavaScript frameworks.
Laravel5.6では、Bladeとeヘルパはデフォルトとして、特別な文字をダブルエンコードします。これにより、裏で動作しているPHPのhtmlspecialchars関数のデフォルトと、この機能は動作が統一されました。ダブルエンコーディングを行わない、以前の振る舞いを継続したい場合は、eヘルパの第２引数に、falseを渡してください。In Laravel 5.6, Blade and the e helper will double encode special characters by default. This brings these features into alignment with the default behavior of the underlying htmlspecialchars PHP function. If you would like to maintain the previous behavior of preventing double encoding, you may pass false as the second argument to the e helper:
<?php echo e($string, false); ?>
ログLogging
新しい設定ファイルNew Configuration File
新しいログ設定は、config/logging.php設定ファイルで全て保存されるようになりました。デフォルト設定ファイルをアプリケーションへコピーし、必要に応じて設定を調整してください。All logging configuration is now housed in its own config/logging.php configuration file. You should place a copy of the default configuration file[https://github.com/laravel/laravel/blob/master/config/logging.php] in your own application and tweak the settings based on your application's needs.
config/app.php設定ファイルから、logとlog_level設定オプションは削除されました。The log and log_level configuration options may be removed from the config/app.php configuration file.
configureMonologUsingメソッドThe configureMonologUsing Method
アプリケーションのために、configureMonologUsingメソッドを使用し、Monologインスタンスをカスタマイズしている場合は、customログチャンネルを作成する必要があります。カスタムチャンネル作成の詳細は、ログのドキュメントで確認してください。If you were using the configureMonologUsing method to customize the Monolog instance for your application, you should now create a custom Log channel. For more information on how to create custom channels, check out the full logging documentation[/docs/5.6/logging#creating-custom-channels].
ログWriterクラスThe Log Writer Class
Illuminate\Log\Writerクラスは、Illuminate\Log\Loggerに名前が変更されました。アプリケーションのクラスで、このクラスをタイプヒントで明確に指定している場合は、新しい名前を参照するように変更してください。もしくは代わりに、標準化されたPsr\Log\LoggerInterfaceインターフェイスをタイプヒントで使うように、よく考慮してください。The Illuminate\Log\Writer class has been renamed to Illuminate\Log\Logger. If you were explicitly type-hinting this class as a dependency of one of your application's classes, you should update the class reference to the new name. Or, alternatively, you should strongly consider type-hinting the standardized Psr\Log\LoggerInterface interface instead.
Illuminate\Contracts\Logging\LogインターフェイスThe Illuminate\Contracts\Logging\Log Interface
Psr\Log\LoggerInterfaceインターフェイスと完全にダブってしまうため、このインターフェイスは削除されました。代わりに、Psr\Log\LoggerInterfaceをタイプヒントに使用してください。This interface has been removed since this interface was a total duplication of the Psr\Log\LoggerInterface interface. You should type-hint the Psr\Log\LoggerInterface interface instead.
メールMail
withSwiftMessageコールバックwithSwiftMessage Callbacks
Laravelの以前のリリースでは、withSwiftMessageを使用し登録した、Swiftメッセージのカスタマイズコールバックは、コンテンツが既にエンコードされ、メッセージに追加された後に呼び出されていました。これらのコールバックが、コンテンツが追加される前に呼び出されるようになり、必要に応じてエンコードや他のメッセージオプションをカスタマイズできるようになりました。In previous releases of Laravel, Swift Messages customization callbacks registered using withSwiftMessage were called after the content was already encoded and added to the message. These callbacks are now called before the content is added, which allows you to customize the encoding or other message options as needed.
ペジネーションPagination
Bootstrap4Bootstrap 4
ペジネータにより生成されるペジネーションリンクが、デフォルトでBootstrap4向けになりました。Bootstrap3向けに生成するように、ペジネータへ指示するには、AppServiceProviderのbootメソッドから、Paginator::useBootstrapThreeメソッドを呼び出してください。The pagination links generated by the paginator now default to Bootstrap 4. To instruct the paginator to generate Bootstrap 3 links, call the Paginator::useBootstrapThree method from the boot method of your AppServiceProvider:
<?php
namespace App\Providers;
use Illuminate\Pagination\Paginator;
use Illuminate\Support\ServiceProvider;
class AppServiceProvider extends ServiceProvider
{
/**
* アプリケーションの全サービスの起動処理
*
* @return void
*/
public function boot()
{
Paginator::useBootstrapThree();
}
}
リソースResources
originalプロパティThe original Property
リソースレスポンスのoriginalプロパティへ、JSON文字列／配列の代わりにオリジナルのモデルがセットされるようになりました。これにより、テスト時にレスポンスのモデルの検査が簡単になりました。The original property of resource responses[/docs/5.6/eloquent-resources] is now set to the original model instead of a JSON string / array. This allows for easier inspection of the response's model during testing.
ルートRouting
新しく生成されたモデルの返却Returning Newly Created Models
ルートから直接、新たに生成されたEloquentモデルをリターンする場合、レスポンス状態は200の代わりに、201が自動的にセットされます。アプリケーションのテストで明確に、200レスポンスを期待している場合は、201を期待するように変更する必要があります。When returning a newly created Eloquent model directly from a route, the response status will now automatically be set to 201 instead of 200. If any of your application's tests were explicitly expecting a 200 response, those tests should be updated to expect 201.
信頼するプロキシTrusted Proxies
Laravelが使用しているSymfony HttpFoundationの、信頼するプロキシの機能変更により、アプリケーションのApp\Http\Middleware\TrustProxiesミドルウェアに、僅かな変更がおきました。Due to underlying changes in the trusted proxy functionality of Symfony HttpFoundation, slight changes must be made to your application's App\Http\Middleware\TrustProxies middleware.
$headersプロパティは以前配列でしたが、様々な異なった値を受け付けるようになりました。たとえば、フォワーディングヘッダを全て信頼するには、$headersプロパティを次のように変更してください。The $headers property, which was previously an array, is now a bit property that accepts several different values. For example, to trust all forwarded headers, you may update your $headers property to the following value:
use Illuminate\Http\Request;
/**
* プロキシを検出するために使用するヘッダ
*
* @var int
*/
protected $headers = Request::HEADER_X_FORWARDED_ALL;
$headersに指定可能な値についての詳細は、trusting proxiesのドキュメントで確認してください。For more information on the available $headers values, check out the full documentation on trusting proxies[/docs/5.6/requests#configuring-trusted-proxies].
バリデーションValidation
ValidatesWhenResolvedインターフェイスThe ValidatesWhenResolved Interface
ValidatesWhenResolvedインターフェイス／トレイトのvalidateメソッドは、$request->validate()によるコンフリクトを避けるために、validateResolvedに変更されました。The validate method of the ValidatesWhenResolved interface / trait has been renamed to validateResolved in order to avoid conflicts with the $request->validate() method.
その他Miscellaneous
laravel/laravel GitHubリポジトリで、変更を確認することも推奨します。変更の多くが必要なくても、それらのファイルを皆さんのアプリケーションで、最新版に合わせておきたいでしょう。変更のいくつかは、このアップグレードガイドで取り扱われていますが、設定ファイルやコメントの変更は取り扱っていません。変更は、GitHub比較ツールで簡単に確認できるので、どの変更が自分にとって重要か選んでください。We also encourage you to view the changes in the laravel/laravel GitHub repository[https://github.com/laravel/laravel]. While many of these changes are not required, you may wish to keep these files in sync with your application. Some of these changes will be covered in this upgrade guide, but others, such as changes to configuration files or comments, will not be. You can easily view the changes with the GitHub comparison tool[https://github.com/laravel/laravel/compare/5.5...master] and choose which updates are important to you.