You are here
Home > Author: khino

パブリックキーを使用してsftp (2) sftponlyの環境で

前回では、Laravel Collective Remoteを利用して、sftpでファイルをアップロード・ダウンロードする話をしました。それだけで事はほとんど足りるのですが、1つ困ったことがありました。

sftpを使用するのは、たいてい自社のサーバーとではなく、他社とのサーバーとです。注文データを取得してくるのも、こちらのデータをアップロードするのも。御存知のように、sftpはsshと同じプロトコルであり、sshが使用できるならsftpも使用可能。しかし、先のような状況だと、セキュリティのために、sftpは使用できるけれど、sshは使用できないようにサーバーが設定されています。また、sftpでは、勝手に他のディレクトリへ行ったりできないように、閲覧できるディレクトリを特定して、jailします。

このような制限された設定となると、例えば以下のように、lsコマンドの実行が不可能となり、ファイルのリストさえ取ってくることできなくなります。

Psy Shell v0.7.2 (PHP 5.6.26 — cli) by Justin Hileman
>>> use SSH;
=> null
>>> SSH::into('acme')->run(['ls data']);
[foo@acme] (acme) This service allows sftp connections only.
..

かと言って、

>>> SSH::into('acme')->list('data');
PHP Fatal error:  Call to undefined method Collective\Remote\Connection::list()

のように、listのコマンドがあるわけでもありません。

いろいろ、探ってみると、

Laravel Collective Remoteは、

https://github.com/LaravelCollective/remote/blob/5.3/src/SecLibGateway.php

では、

以下のphpseclibというパッケージを使用しています。

https://github.com/phpseclib/phpseclib/blob/master/phpseclib/Net/SFTP.php

これらを参考にすると、

>>>SSH::into('acme')->getGateway()->getConnection()->nlist('data');
=> [
     "base-invoice.csv",
     "base-product.csv",
     ".",
   ]
..

というように、nlistを実行できます。

他にも、chdirとも実行できるようです。オープンソースのおかげでこういう問題自分で解決できます。

パブリックキーを使用してsftp

中規模のECを営む私のお客さんのところでは、自社製品を持ち出荷するゆえに、自社のウェブで販売するのみではなく、他社でのウェブサイトでも製品が売られています。となると、そこからも注文データが来ます。

その発注データは、ウェブサービスを使用したAPIを使用して取得、というようなものではなく、彼らが生成した注文データをCSVファイルとして指定のサーバーに置かれ、それを毎日sftpでダウンロードして、システム内に取り込みます。

また、逆に自社サイトで販売した注文情報を、出荷や解析の目的で他のサーバーにsftpでアップロードというケースもあります。

ここで重要なのは、パブリックキーを使用したsftpのコミュニケーションが必要なことです。

そこで登場するのが、以前会員編集フォーム紹介した、Laravel Collectiveです。

Laravel Collectiveのインストール

最初に、以下をコマンドラインで実行します。

$ composer require "laravelcollective/remote":"^5.3.0"

この実行で、必要なライブラリがインストールされ、composer.jsonが更新されます。

次に、config/app.phpのファイルをエディタで開き、以下を追加します。

  'providers' => [
    // ...
    Collective\Remote\RemoteServiceProvider::class,
    // ...
  ],

  'aliases' => [
    // ...
    'SSH' => Collective\Remote\RemoteFacade::class,
    // ...
  ],

設定

SSHのパッケージがインストールされたところで、次は設定です。Laravel用に開発されたパッケージでは、たいていはパッケージ独自の設定ファイルを、config/ディレクトリに作成します。

以下を、コマンドラインで実行してください。

$ php artisan vendor:publish --provider="Collective\Remote\RemoteServiceProvider"

この実行により、config/remote.phpの設定ファイルが作成されます。

エディターで、そのファイルを開き、acmeエントリーを追加します。acmeでなくても、名前はなんでもよいです。

  'default' => 'production',

  'connections' => [
        'production' => [
            'host'      => '',
            'username'  => '',
            'password'  => '',
            'key'       => '',
            'keytext'   => '',
            'keyphrase' => '',
            'agent'     => '',
            'timeout'   => 10,
        ],

        'acme' => [
            'host'      => env('ACME_HOST'), // sftp先
            'username'  => env('ACME_USERNAME'), // ログイン名
            'password'  => '', // 
            'key'       => base_path(env('ACME_KEY')), // パブリックキーファイルのパス名',
            'keytext'   => '',
            'keyphrase' => '', 
            'agent'     => '',
            'timeout'   => 10,
        ],
    ],

見ての通り、このファイルにはデフォルトとして、すでにproductionがありますが、それには触らず、ここではacmeの配列を新設しました。開発サイトでのテストも考えて、いろいろな情報をここで設定できるのは便利です。

今回は、バージョン管理にプライベートの値が入らないように、.envで指定するようにしました。特に、大きい値のパブリックキーを含むファイルを、keyで指定できるのも便利です。このファイルは、.gitignoreで必ずバージョン管理から排除が必要ですね。

keyphraseは、パブリックキーを生成したときに指定したパスワードを入れますが、パスワード指定なしで作成することが多いです。それでも十分セキュアであるのでここでは空とします。

.envでは、以下のような変数を追加します。

..
ACME_HOST=foo.google.com
ACME_USERNAME=foo
ACME_KEY=config/keys/test.pem
..

以上でテスト可能となります。もし、sftp先でsftpのみで設定されていないなら、

$ php artisan tinker

を実行して、接続テストができます。以下では、sshでacmeに接続して、lsコマンドを実行しました。

Psy Shell v0.7.2 (PHP 5.6.25 — cli) by Justin Hileman
>>> use SSH;
=> null
>>> SSH::into('acme')->run(['ls']);
[foo@acme] (acme) data.csv
=> null
>>> 

sftpでファイルのダウンロード・アップロード

ここまで来たら、あとは簡単です。プログラムの中で以下を実行するだけです。

ファイルのダウンロードは、

SSH::info('acme')->get('data.csv', storage_path('data.csv'));

ファイルのアップロードは、

SSH::info('acme')->put(storage_path('data.csv'), 'data.csv');

あたかも、コマンドラインで実行するような軽さですね。

グローバル変数をダイナミックに管理

Laravelのバージョンが5になってから、グローバルスコープを持つ変数の設定は、.envconfig/のディレクトリの設定ファイルで、実用的しかも綺麗にまとまりました。変数の使用も、config('app.url')と、プログラムのでどこでも簡単に取得できます。

また、DBの設定などのデフォルト設定ファイル以外にも、独自の設定ファイルも作成できます。

例えば、

config/local.phpというファイルを作成して、


return [
        'convert' => '/usr/bin/convert', // 画像変換のプログラムのパス名
        'items_per_page' => 50,          // 1ページのアイテム数
        'max_upload_size' => 20,         // 最大アップロードの画像サイズ(MB)
        'company' => env('LOCAL_COMPANY', 'Lots of Bytes'), // 会社名
];

とすれば、config('local.company')と参照できます。

しかし、これらのグローバル変数設定の問題は、プログラムとして設定ファイルあるいは.envでハードコードしなければならないことです。

グローバル変数をDBに値を保存して、管理画面で以下のように値を編集できて、プログラムの各所で使用できるようにするには、どうしたらよいのでしょうか?

my-application

幸いにも、config()の関数は、取得だけでなく書き込みも可能なのです。


config(['global.admin_email' => 'abc@gmail.com']);

というように実行すれば、config('global.admin')abc@gmail.comを返すことができます。

global.とプリフィックスしたのは、単に他の変数と区別やグループ分けがしたいがためです。

ということは、DBからデータを読んでプログラムの実行時の最初に、configして入れしまえば良いわけです。

このための適切な場所は、プログラムの初期に実行される、app/Providers/AppServiceProvider.phpの中です。


namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use DB;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
	$setting = DB::table('setting')->pluck('value', 'key');

	config(['setting' => $setting]);        
    }
...
}

DBテーブルsettingの中身は、以下とすると、

+------------+---------------------+---------------------+------------------+-------------------+
| setting_id | created_at          | updated_at          | key              | value             |
+------------+---------------------+---------------------+------------------+-------------------+
|          1 | 2016-12-03 01:09:51 | 2016-12-03 01:09:51 | email_admin      | admin@gmail.com   | 
|          2 | 2016-12-03 01:09:51 | 2016-12-03 01:09:51 | email_from       | from@gmail.com    | 
|          3 | 2016-12-03 01:09:51 | 2016-12-03 01:09:51 | site_name        | ララジャパン       | 
+------------+---------------------+---------------------+------------------+-------------------+

例えば、config('setting')['site_name']の実行では、ララジャパンの値が返ってきます。

Laravel 5.3 タイムスタンプのDB項目名の指定

Laravel 5.3に更新して、Eloquentのモデルの設定において嬉しいこと発見しました。

LaravelのEloquentでは、指定のDBテーブルにおいて、作成日時と編集日時に、規定のcreated_atupdated_atの項目名が使用されているなら、いちいち、

use Users;
use Carbon\Carbon;

$user = new Users;
...
$user->created_at = $user->upddated_at = Carbon::now();

$user->save();

というようなことを、DBレコードの追加や編集の際に、書かなくとも自動で作成日時と編集日時に値を入れてくれます。

私のケースでは、既存のプロジェクトのDBにおいて、作成日時と編集日時には、date_createddate_modifiedと違う名前を使用していて、今まで「いちいち」コードで指定していました。

しかし、Laravel 5.3では、以下のようにモデルの定数(const)を指定することで、項目名を指定できるようになりました。


namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Company extends Model
{
	protected $table = 'company';
	protected $primaryKey = 'company_id';
	public $timestamps = true; //デフォルトではtrueなので、指定する必要はない

	const CREATED_AT = 'date_created';
	const UPDATED_AT = 'date_modified';
..

これは大変便利です。

もう1つ便利なことで最近見つけたことは、最初の例で使用したCarbonは、Laravelをインストールしたら一緒にインストールされるパッケージですが、使い勝手あります。

例えば、DBに記録した日時から現在までの「経過日数」を計算するには、

$days_past = (new Carbon($user->updated_at))->diff(Carbon::now())->days;

簡単でわかりやすいですね。これをphpでやろうとすると、文字列から秒数に変換してなどと大変です。

最後に、日時の使用で忘れてならないのは、必ずアプリの設定ファイルで、タイムゾーンを設定すること。

..
    'timezone' => env('APP_TIMEZONE', 'Asia/Tokyo'),
..

ログイン成功のイベント

ユーザー認証(11)Laravel 5.2 ログインの記録で、ログイン成功後の処理に関して説明しました。

しかし、前回のログインのRemember Meのポストのための調査で、この「Remember Me」がオンになっているときは、先のログイン成功後の処理は、最初のログインのときだけしか実行しないことを見つけました。

つまり、最悪のケース、5年間ログイン成功後の処理は実行されません。同じブラウザを使用してもIPアドレスが変わることがあるし、記録としても不十分となり不都合です。

さて、どう解決したらよいでしょうか?

これにはLaravelのイベントのメカニズムを利用します。イベントの仕組みは、イベントとリスナーの2つのクラスの定義から構成され、イベントのクラスのオブジェクトをプログラムの中でコール(ファイヤー)することでリスナーのオブジェクトのアクションが実行されます。

例えば、ログインが成功したときに希望するアクション(ログインの記録)を実行したいときは、ログイン成功のイベントとそのリスナーを作成します。

ありがたいことに、ユーザー認証に関してのイベントは、すでにIlluminiate\Auth\Eventsで定義されており、Illuminiate\Auth\SessionGuardのクラス内のメソッドで要所要所でファイヤーされています。

イベントの種類としては、以下が揃っています。

Attempting ログインを試みたとき
Authenticated ログイン成功後のセッションにアクセスするとき
Failed ログインが失敗したとき
Lockout ログイン連続失敗でロックアウトされたとき
Login ログインが成功したとき
Logout ログアウトしたとき
Registered 会員登録完了したとき

今回は、Loginのイベントが使えそうです。

コードをチェックしたところ、Remember Meがオンのときも、このイベントをファイヤーします。

最初にログイン成功したときだけでなく、デフォルトでは2時間アイドル後にセッションが切れるときや、ブラウザを閉じて再度オープンするときなど、再度ログインが必要なときにRemember Meの情報を使用して自動ログインするときにも、このイベントがファイヤーされます。

ということで、イベントのクラスはすでにあるので、このイベントに対応するリスナークラスを作成して登録すれば作業終了です。

ログイン成功のイベントLoginに対して、リスナーを作成してみましょう。逆になりますが、まず登録から始めます。

登録は、

namespace App\Providers;

use Illuminate\Support\Facades\Event;
use Illuminate\Foundation\Support\Providers\EventServiceProvider as ServiceProvider;

class EventServiceProvider extends ServiceProvider
{
    /**
     * The event listener mappings for the application.
     *
     * @var array
     */
    protected $listen = [
        'Illuminate\Auth\Events\Login' => [
            'App\Listeners\LoginListener',
        ],
    ];

    /**
     * Register any events for your application.
     *
     * @return void
     */
    public function boot()
    {
        parent::boot();

        //
    }
}

$listenの変数に、イベントに対応するクラスを指定するだけです。

次にリスナーのクラスを作成しますが、先の登録が完了していれば、便利なことに以下をコマンドラインで実行するだけで作成してくれます。

$ php artisan event:generate

もちろん、以下でも作成可能です。

$ php artisan make:listener LoginListner --event=Illuminate\Auth\Events\Login

作成された、リスナーを以下のように編集します。


namespace App\Listeners;

use Illuminate\Auth\Events\Login;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Http\Request;

use App\UserLog;

class LoginListener
{
    /**
     * Create the event listener.
     *
     * @return void
     */
    public function __construct(Request $request)
    {
        $this->request = $request;
    }

    /**
     * Handle the event.
     *
     * @param  Illuminate\Auth\Events\Login  $event
     * @return void
     */
    public function handle(Login $event)
    {
        $user = $event->user;

        $ip = $this->request->ip();
        $agent = $this->request->header('User-Agent');

        UserLog::crate([
            'user_id'     => $user->id,
            'ip'          => $ip,
            'hostname'    => gethostbyaddr($ip),
            'agent'       => $agent
        ]);
    }
}

これで、ユーザーがログインをしたときや、セッションが期限切れで失って自動ログインされるときに、ログインの記録のレコードを作成してくれます。

ログインのRemember Me

Laravel 5.3になって、認証の部分が変りました。それに関していっぱい紹介したいことありますが、それは将来でのポストとして、今回は、「ログインのRemember Me」に関して学んだことを紹介します。

以下の画面のようにログインには、

my-application

「Remember Me」あるいは「次から入力を省略」、ログインのときにオンとすると次回から毎回毎回ログインする必要ないよという便利な機能。巷ではどこでも見かけます。

Laravelでも、認証のパッケージのインストール、

$ php artisan make:auth

を実行すると、デフォルトでついてくる機能です。

さて、この「Remember Me」でどうやってログインを要らなくするのか、そのメカニズムを探ってみましょう。

まず、「Remember Me」をクリックしてログイン成功すると、以下のように2つのクッキーを作成します。

  • laravel_session

    通常のセッションのためのクッキー。期限は、

    ..
        'lifetime' => 120,
        'expire_on_close' => true,
    ..
        'cookie' => 'laravel_session',
    ..
    

    lifetimeあるいはexpires_on_closeの値で決定されます。

    デフォルトでは、前者が2時間(120分)、後者は、fale。後者をtrueとするとブラウザをクローズしたときに期限切れとなります。ちなみに、このクッキーの名前は、cookieの値で変更可能です。

  • remember_web_59ba36addc2b2f9401580f014c7f58ea4e30989d

    こちらは、「Remember Me」のためのクッキーで、Laravelではログインした日から5年間と期限はハードコードされています。つまり、同じブラウザを使用し続けるなら、ログオフしない限り5年間ログインなしでアクセス可能です。

このクッキーが使用されるシナリオは簡単にはこうです。

ログイン後、2時間アイドルが続いたらあるいはブラウザを閉じたら、現在のセッションは無効になります。

セッションが無効となると、ユーザーの認証が不可能となります。なぜなら、セッションの中に含まれていたユーザーのIDの取得が不可能となるからです。そうなるとログインの画面に遷移して、再度ログインしなければなりません。

しかし、「Remember Me」をオンとしてログインしていたなら、この時点で、まだ期限までたっぷり時間がある「Remember Me」のクッキーを見に行きます。

このクッキーの中には、暗号化されたユーザーIDが入っているので、それを非暗号化して再度セッションを作成します。これにより、再度ログインをすることなしに、ログインした状態をキープすることが可能となるのです。

Laravel 5.3 resourceでの名前付きrouteの変更

以前に、Route::resourceの便利さを紹介しました。

routesを使いこなす(1)resourceを使う

routesを使いこなす(2)resourceを使いこなす

また、名前付きrouteがもたらす便宜さも紹介しました。

routesを使いこなす(4)routeを名付ける

しかし、Laravel 5.3のバージョンアップで「ちょっと、それはないよ」みたいな問題が出てきました。

Route::resourceでは、名前付きrouteが自動で作成されます。

例えば、Laravel 5.2では、routes.phpにこう設定すると、

Route::group(['prefix' => 'admin', 'middleware' => 'web', 'namespace' => 'Admin'], function () {

    Route::resource('product', 'ProductController');

});

以下のように名前付きroutesがprefixをもとに設定されます。「Name」の列です。

+--------+-----------+------------------------------+-----------------------+---------------------------------------------------------------+------------+
| Domain | Method    | URI                          | Name                  | Action                                                        | Middleware |
+--------+-----------+------------------------------+-----------------------+---------------------------------------------------------------+------------+
|        | POST      | admin/product                | admin.product.store   | App\Http\Controllers\Admin\ProductController@store            | web,web    |
|        | GET|HEAD  | admin/product                | admin.product.index   | App\Http\Controllers\Admin\ProductController@index            | web,web    |
|        | GET|HEAD  | admin/product/create         | admin.product.create  | App\Http\Controllers\Admin\ProductController@create           | web,web    |
|        | DELETE    | admin/product/{product}      | admin.product.destroy | App\Http\Controllers\Admin\ProductController@destroy          | web,web    |
|        | PUT|PATCH | admin/product/{product}      | admin.product.update  | App\Http\Controllers\Admin\ProductController@update           | web,web    |
|        | GET|HEAD  | admin/product/{product}      | admin.product.show    | App\Http\Controllers\Admin\ProductController@show             | web,web    |
|        | GET|HEAD  | admin/product/{product}/edit | admin.product.edit    | App\Http\Controllers\Admin\ProductController@edit             | web,web    |
+--------+-----------+------------------------------+-----------------------+---------------------------------------------------------------+------------+

しかし、おなじ、routes.phpをLaravel 5.3に持っていくと(もちろん、web.phpと改名して、app/Httpからroutes/のディレクトリに移して)、

+--------+-----------+------------------------------+-----------------+---------------------------------------------------------------+------------+
| Domain | Method    | URI                          | Name            | Action                                                        | Middleware |
+--------+-----------+------------------------------+-----------------+---------------------------------------------------------------+------------+
|        | POST      | admin/product                | product.store   | App\Http\Controllers\Admin\ProductController@store            | web,web    |
|        | GET|HEAD  | admin/product                | product.index   | App\Http\Controllers\Admin\ProductController@index            | web,web    |
|        | GET|HEAD  | admin/product/create         | product.create  | App\Http\Controllers\Admin\ProductController@create           | web,web    |
|        | DELETE    | admin/product/{product}      | product.destroy | App\Http\Controllers\Admin\ProductController@destroy          | web,web    |
|        | PUT|PATCH | admin/product/{product}      | product.update  | App\Http\Controllers\Admin\ProductController@update           | web,web    |
|        | GET|HEAD  | admin/product/{product}      | product.show    | App\Http\Controllers\Admin\ProductController@show             | web,web    |
|        | GET|HEAD  | admin/product/{product}/edit | product.edit    | App\Http\Controllers\Admin\ProductController@edit             | web,web    |
+--------+-----------+------------------------------+-----------------+---------------------------------------------------------------+------------+

なんと!
admin.product.store ⇒ product.store とadmin.が皆消えてしまいました。

ドキュメントを読むと、どうもこのprefixの設定は、resourceの名前付きrouteに反映される意図はなかったとのことで、5.3で修正という訳です。

以前と同様な、名前付きのrouteとするためには、asを使用して、以下のように設定します。

Route::group(['prefix' => 'admin', 'as' => 'admin.', 'middleware' => 'web', 'namespace' => 'Admin'], function () {

    Route::resource('product', 'ProductController');

});

注意:adminでなく、admin.です。最後にドットが必要。

あるいは、ひとつひとつを命名するというオプションもあります。しかし、これはちょっと。。

Route::group(['prefix' => 'admin', 'middleware' => 'web', 'namespace' => 'Admin'], function () {

    Route::resource('product', 'ProductController', ['names' => ['index' => 'admin.product.index']]);

});

Laravel 5.3 AWS S3にファイルをアップロード

アップロードしたファイルの保存のメソッドがLaravelで5.3で少し変わりました。ここでそれらの情報更新とともに、AmazonのストレージサービスS3にファイルをアップロードする仕方を紹介します。

まず、準備から、

パッケージの追加と設定

コマンドラインで以下の実行が必要です。


composer require league/flysystem-aws-s3-v3 ~1.0

これにより、

config/filesystems.php

の設定ファイルが作成されます。


return [
    'default' => 'local',
    'cloud' => 's3',

    'disks' => [

        'local' => [
            'driver' => 'local',
            'root' => storage_path('app'),
        ],

        'public' => [
            'driver' => 'local',
            'root' => storage_path('app/public'),
            'visibility' => 'public',
        ],

        's3' => [
            'driver' => 's3',
            'key' => 'AWSのキー',
            'secret' => '秘密のキー',
            'region' => '地域のコード', // 日本なら、ap-northeast-1
            'bucket' => 'バケット名'
        ],
    ],
];
    

localは、使用しているサーバーのストレージのことです。

rootは、Laravelをインストールしたディレクトリのサブディレクトリ、storage/appの場所となります。

publicは、ウェブユーザーにアップロードしたファイルをパブリックに紹介する場所です。

以下の実行で、public/storageが、storage/app/publicにリンクされます


php artisan storage:link

例えば、アップロードされたファイルは、

storage/app/public/mario.jpg

に保存され、

http://localhost/public/storage/mario.jp

で閲覧できるということです。

s3のkey, secret, region, bucketの指定は必須です。これらは、Amazonのウェブサービスのコンソールで取得できます。

これで設定終わりです。

ファイルのアップロードのプログラム

簡単なファイルのアップロードのプログラムを書いてみます。

まず、routeの設定から、


    Route::get('upload', 'UploadController@create');
    Route::post('upload', 'UploadController@store');

これで、

http://localhost/upload

にアクセス可能です。

次にコントローラ、

namespace App\Http\Controllers;

use Illuminate\Http\Request;

use Storage;

class UploadController extends Controller
{
    public function create()
    {
        return view('upload');
    }

    public function store(Request $request)
    {
        $filename = $request->file('image')->getClientOriginalName(); //アップロードしたファイル名を取得

        $path = $request->file('image')->storeAs('public', $filename);

        return back()->with('filename' => $filename);
    }
}

storeAs('public', $filename);

この最初のパラメータは、ファイルを保存するディレクトリ名です。先のconfig/filesystems.phpの設定で、storage/appがルートのディレクトリゆえに、上のコードではstorage/app/publicにファイルが保存されることになります。

ファイル名がmario.jpgであれば、

storage/app/public/mario.jpg

と保存されます。

ファイルをアップロードするフォームのブレードは、


@extends('layouts.app')

@section('content')
<div class="container">
    <div class="row">
        <div class="col-md-8 col-md-offset-2">
            <div class="panel panel-default">
                <div class="panel-heading">Media Upload</div>
                <div class="panel-body">
                    <form class="form-horizontal" role="form" method="POST" action="{{ url('upload') }}" enctype="multipart/form-data">
                        {{ csrf_field() }}

                        <div class="form-group">
                            <label for="image" class="col-md-4 control-label">File</label>

                            <div class="col-md-6">
                                <input id="image" type="file" name="image">
                            </div>
                        </div>

                        <div class="form-group">
                            <div class="col-md-6 col-md-offset-4">
                                <button type="submit" class="btn btn-primary">
                                    Upload
                                </button>
                            </div>
                        </div>
                    </form>
                </div>
            </div>
        </div>
    </div>
    <div class="row">
        <div class="col-md-8 col-md-offset-2">
            <div class="panel panel-default">
                <div class="panel-body">
                @if (session('filename'))
                    <h4>Local</h4>
                    <img src="{!! asset('storage/'.session('filename')) !!}">
                @endif
                </div>
            </div>
        </div>
    </div>
</div>
@endsection

先の例で、ファイル名が、mario.jpgならば、

asset('storage/'.session('filename'))

は、

http://localhost/public/storage/mario.jpg

のようになるわけです。

ファイルをアップロードした後の画面はこんな感じです。
my-application

S3に画像をアップロード

さて、サーバーにアップした画像を、今度はS3にアップするのですが、これはconfig/filesystems.phpの設定が済んでいれば、本当に簡単です。

コントローラのstoreメソッドにたったの2行追加するだけです。


   public function store(Request $request)
    {
        $filename = $request->file('image')->getClientOriginalName();

        $path = $request->file('image')->storeAs('public', $filename);

        $contents = Storage::get('public/'.$filename); //ファイルを読み取る
        Storage::disk('s3')->put($filename, $contents, 'public'); // S3にアップ
 
        return back()->with(['filename' => $filename]);
    }

>put($filename, $contents, 'public')

ここのpublicに注意してください。これがないと一般には公開されません。

以下のAWSのコンソールの赤箱の部分がそれにより追加されます。

s3-management-console

先の画面にS3から直接画像を表示したいなら、ブレードに以下の変更を。

    <div class="panel-body">
    @if (session('filename'))
       <h4>Local</h4>
       <img src="{!! asset('storage/'.session('filename')) !!}">
       <h4>S3</h4>
       <img src="{!! Storage::disk('s3')->url(session('filename')) !!}">
    @endif
    </div>

S3の以下のURLが生成されます。

https://s3-us-west-2.amazonaws.com/demo53/mario.jpg

us-west-2は、設定に使用した地域コードです。日本ならap-northeast-1となります。

Laravel 5.3 コントローラのコンストラクタの重要な変更

Laravelのバージョン5.3がリリースされてから、かれこれ1ヶ月。使い始めてみました。

以前のバージョンからバージョン5.*への変更に比べれば、そう注意しなければならない変更はないのだけれど、とっても注意することありました。

Laravel5.2では、コントローラのコンストラクタでこんなこと可能でした。


namespace App\Http\Controllers;

use Illuminate\Http\Request;

use Auth;

class HomeController extends Controller
{
    protected $options;

    public function __construct()
    {
        $user = Auth::user();

        $this->options = $user->options; //ログインしたユーザーの設定オプションを取得
    }
}

認証されたユーザー、つまりログインしたユーザーの認証の情報にアクセスすることが、コントローラのコンストラクタで可能でした。

同じコントローラの他のメソッドで何回も同じことを行うのは面倒なわけで、また以下のようにすでにroutes.php(5.3では、app/routes/web.phpとなります)の設定で、パスワード保護されているので、認証されたユーザーの情報を共有できる理想の場所というわけです。

Route::get('login', 'Auth\AuthController@showLoginForm');
Route::post('login', 'Auth\AuthController@login');
Route::get('logout', 'Auth\AuthController@logout');

Route::group(['middleware' => 'auth'], function() {
	Route::get('home', 'HomeController@index');
});

しかし、それは「してはいけないこと」だったのです!Laravel5.3になるやいなや、認証したユーザーのAuth::userがnullを返すようになりました。

そして、Laravelの作者(Mr. Tayler)の思惑とは逆に、こんなことをやっている開発者はごまんといたわけです。

以下のやり取りをみていると、

突如の変更に困ったユーザーとそれに対応する作者たちの会話

作者は、ユーザー認証はクッキーやセッションがあってこそ成り立つものであり、それが入ってくるのはコントローラのメソッドにおいてのrequestの引数である。それゆえにrequestがないコンストラクタでその情報を取得するのはデザイン上「悪い」と。

しかし、コンストラクタはいろいろと共有できる便利な場所であり、しかも今までそこで問題なかったのだからね。

作者もそれを理解して、すぐに以下のような対応をしてくれました。


    public function __construct()
    {
        $this->middleware(function ($request, $next) {
            $this->options = Auth::user()->options;//ログインしたユーザーの設定オプションを取得

            return $next($request);
        });
    }

Laravel 5.3.4からの対応です。

ちょっとしたパフォーマンスの改善

Laravelは非常にたくさんのファイルを起動時に読み込んでいるので、パフォーマンスの改善は以前から感心があります。最近、管理画面だけでrouteの数が300近いプログラムをインストールするにあたり、重たくなることを予想して、簡単にできる範囲でLaravelでのパフォーマンスの改善を調査してみました。

1.設定ファイルのキャッシュ作成

php artisan config:cache

この実行は、configのディレクトリにあるファイルすべてを合わせて1つのキャッシュファイルにします。これにより設定データのローディング時間を速めようということです。

ファイルは、

bootstrap/cache/config.php

として作成されます。

この使用において、注意は3点あります。

注意点1:プログラムにおいてenv()の関数を使用してはいけない

例えば、

.envのファイルにおいて、

APP_ENV=local

と設定していて、

$path = storage_path().'/'.env('APP_ENV').'/logs/test.log';

のように、現在の環境変数の値によりログファイルを置くディレクトリを変えるとすると、

$pathの値は、

/var/www/test/storage/local/logs/test.log

のようになります。

しかし、php artisan config:cacheを実行すると、env()の値は空となり、

/var/www/test/storage/logs/test.log

となってしまい、意図した場所とは違うことになってしまいます。

それゆえに、先のプログラムは以下と変更することが必要です。

$path = storage_path().'/'.config('app.env').'/logs/test.log';

もちろん、config/app.phpなどの設定ファイルの中でのenv()の使用は問題ないです。

注意点2:ダイナミックに値を設定しているconfigに気をつける

設定ファイルの値は、

config(['some_setting' => 'some_value']);

のようにダイナミックに値の設定が可能です。例えば、DBからの値をAppServiceProvider::boot()で読み込んでおいて、DBに再度アクセスすることなくプログラムのあちらこちらで使用しようというときなどに便利です。

ところが、php artisan config:cacheの実行時に、AppServiceProvider::boot()が実行されるので、それらの設定もキャッシュファイルに保存されてしまいます。これで、ダイナミックに変わる値が固定されては困ります。

しかし、ダイナミックに上書きされるので問題はなさそうです。しかし、プログラムの他の部分では問題があるかもしれません。使用には気をつけてください。

注意点3:.envやconfigのファイルを編集したら、必ずキャッシュを再作成

最後に忘れてはならないのは、.envconfig/*.phpのファイルを編集したら、必ずphp artisan config:cacheの実行が必要なことです。それなくしては、せっかくの変更も反映されません。

2.routeのキャッシュ作成

php artisan route:cache

こちらは、config:cacheと違い、この実行で作成されるファイル、

bootstrap/cache/routes.php

には、routes.phpファイルを読み込んでLaravelがマップしたデータ構造をbase64_encodeして、serializeした形で収めます。それゆえに、この読み込みとマップの作業を一気に短縮します。とくに、routeの数が大きいプロジェクトではパフォーマンスの改善に期待できる仕組みです。

それからconfig:cacheと同様に、routes.phpファイルを編集したら、必ずphp artisan route:cacheの実行が必要です。

3.共有クラスファイルの最適化

これは、環境変数のAPP_ENVがproductionの値のときにだけに有効なものです。また、設定ファイルに依存するので、設定ファイルをキャッシュするなら、php artisan config:cacheを実行してから以下を実行してください。

php artisan optimize

この実行で、共有されるクラスファイルを1つのファイルにまとめ、読み込み時間を短縮するのが目的です。以下のファイルを作成します。

bootstrap/cache/compiled.php

このファイルには、デフォルトでは、Laravel関連のファイルが含まれますが、必要なら以下の設定ファイルに追加が可能です。

bootstrap/cache/compile.php

改善した?

さて、実際にこれらの最適化でパフォーマンスはどれくらい変わるのでしょうか?

私の厳密ではないテストでは、DB操作を伴わない計測では10~30%の違いがありました。configよりもrouteやoptimizeの方が実際のパフォーマンスにより影響ありました。多分、設定ファイルが小さく数少ないためがその違いと思います。しかし、現実では、DBクエリーやCSS、JS、画像などのダウンロードがはるかに時間がかかるので、まだ私のプロジェクトのスケールではちょっとした改善というところです。スケールがより大きくなるとかなりの差となるかもしれません。

Top