API周りの実装ですが、Laravelにはこのあたりに必要な機能が始めから入っているためかなり楽に作りこむことができます。Laravelのコントローラーで文字列、もしくは配列をreturnするとjson_encode()しなくても勝手にjsonに変換してくれたり、ステータスコードを付加するのがかなり簡単だったりとほぼそのまま使える状態になっています。URLとコントローラーのメソッドを対応させるルーティングについても、デフォルトでAPI用のルーティングファイル(routes/api.php)が別で用意されており、APIのルーティングだけ、Web部分のルーティングと分離して書くことができます。api.phpに書かれたルートにアクセスするにはexample.com/api/...のように、urlにapiというディレクトリ名を挟むだけです。API使用時の認証の部分。簡易的な認証であれば、DBのユーザー情報テーブルに”api_token”というカラムを追加して、このカラムに対してユーザー登録時にapiトークンを自動生成するようにしておけばLaravelのデフォルトのメソッドを使用してapiトークンによる認証を行わせることができるようになっているのですが、このapi_tokenにあたるカラム名をカスタマイズしたりだとか、Twitterのように、トークン+セキュリティトークンの2つで認証させるようにカスタマイズしたい場合などにカスタマイズが簡単にできない点があり、独自に実装してしまった方が早い...という側面があります。このあたりがもっと改良されてこればより実用的になると思うのですが...かゆいところに手が届かない感があってつらいところです。(0)2210月,20190著者:杉浦.envファイルの読み方色々.envは環境変数を定義するファイルとしてよく使われているファイル名です。この記事はいくつかの言語、フレームワークにおける.envの読み方の紹介をします。今どきの環境は.envがあることを前提として作られている機能があります。PHPのフレームワークであるLaravelやJavaScript実行環境であるNode.jsです。PHP_VERSION=${PHP_VERSION}AltJSをコンパイルする環境ならば特定の接頭辞の環境変数を定数をあてはめる形で実装されていることが多いです。process.env.MIX_VERSION;Pythonの様にdotenvというパッケージがある場合もあります(Rubyもそうらしい)。環境変数から値を取得ちょっと手間ですがbashの中で読むこともできます。dd()の様なデバッグ用にリッチな画面出力関数が用意されています。dddはそれに加わる新たなデバッグ用関数です。NewsLaravel6.xではエラーページ用の機能がLaravel/Ignitionになっています。dddはこのIgnitionに付属する機能です。Ignitionのエラーページは画像の様な白を基調とした画面で今までの黒画面とはガラッと変わりました。タブ毎にデータを分けることで肥大化したデバッグ用情報を読みやすくしています。Newsから引用ddd関数は画面出力をこのエラーページ同様にリッチなものにします。ddd関数を使うことでリクエスト、ログイン情報、発行されたSQLなども合わせて見ることができます。いうComposerパッケージを使用すると非常に楽です。詳しいセットアップ方法は、下記のサイトを参考にしてみてください。save()メソッドを使った保存方法を紹介しているところが多いです。500);...しかし今回僕が行いたかった処理は”元ファイルを変換して保存する”のではなく、”元画像を圧縮してサムネイル画像を作成してRestAPI経由でbase64でクライアントに投げる”ということをしたかったため、ファイルの保存は不要でした。ファイルへ保存ではなく、バイナリストリームをそのまま吐き出すメソッドが存在していることを知りました。);のようにすると、base64に変換されたデータが入手できます。これで、目的の動作をさせることがきました。Laravelでは$image->save(画像の保存先パス);すると権限の問題でエラーになってしまいます。データを保存することができます。の”fillable”の設定がめんどくさいときは”guarded”が便利PHPフレームワークのLaravelには、DBと接続してデータをやり取りする仕組みとして”Eloquent”が実装されています。基本的なDB操作であれば始めからメソッドが用意されているため、Modelに自分でメソッドを書かなくても簡単にデータが取得、保存ができるためとても便利です。上記の備え付けのメソッドを使用する際は、DBの設定(テーブル名や主キーなど)をModelに記述する必要があります。この設定の一つに、どのテーブルへのアクセスを許可するか、という指定があります。この指定を行っておくことで、本来データを入れてはいけないテーブルに対して、誤ってModelからアクセスしてしまうことを防ぐことができます。必須の項目なので、何らかの指定は必要になります。個人的によくサイトで見かける方法で、Model内のクラスのブロックの頭に$fillableという変数を置くものがあります。....fillableでは何を指定すればいいのかというと、”Laravel側から触ってもよいカラム”を指定します。これでも動作としては問題がないのですが、カラム数の多いテーブルなどが多かったりすると、正直めんどくさくなってきます...実はもう一つ、操作可能なカラムを指定する方法があります。変数を用いる方法です。ブラックリスト方式です。指定した場合は”アクセスしてはいけない”カラムだけ記述すればOKです。アクセスしてはいけないカラムが、アクセス可能なカラムよりも数が少ない場合はこちらの方が楽ですね。LaravelのModelでは、fillableかguardedのいずれかが指定されていればOKとなっていますので、うまく使い分けて記述量を減らしていきましょう。Initializerという記法が現在提案されています。Externalsその名の通り、オブジェクトの初期化に関する記法です。具体的には次の様な記述をします。単なる代入によるpublicプロパティの初期化をコンストラクタ外で行おうとする方法です。これによりコンストラクタのコーディング、プロパティの代入忘れ、引数の順番間違いから解放されます。17:30(JST)時点で3:17です。投票に理由をコメントする必要はないのでスレを読み取って想像するしかありませんが、コンストラクタと共存すると怪しかったり、__setを介する直接代入でない部分の扱いだったり、今のPHPでも手間をかければ似たようなことができたりで賛成者は少ないです。PHPの既にある仕様で多数のプロパティを初期化する方法は多々あります。フレームワークを利用するとさらに増えます。自分がよく使うのは連想配列を用いたパターンです。139.745451]);連想配列にまとめることで引数を抑え、連想配列であるため引数の意味を理解しやすい、というものです。このやり方にはIDEの自動補完がまるで働かないという点で問題がありますが、程よく手軽に使える点と他クラスのarray変換ですぐ結び付けられる点で使用しています。他にもstdClassを使ったパターンやインタフェースとDTO(DataTransfarObject)を使うやり方もあります。後者は大がかりなものを扱う時、重用できます。}}初期化とは少し違いますがLaravelのFormRequestとEloquentをつなぐやり方として次のワンライナーがあります。User::create($request->validated());}validatedメソッドの返り値はバリデーションを通過したリクエストのボディ全ての連想配列です。リクエストのキーをテーブルのキーと一致させることによって上記の記述でブラウザのリクエストからデータベースへのSQL発行まで一気に繋げられます。バリデーション通過済みなので安全な値です。【Laravel】EloquentモデルのObserverの活用LaravelのEloquentにはObserverという仕組みがあります。ObserverはEloquentのイベント発生によって発火するメソッドの集まりです。Laravel#オブザーバObserverは次のようにartisanでボイラープレート的なモノを生成できます。--model=User以下の様に生成されたクラスをLaravelの起動時処理で登録することによってイベント監視が動作します。}}オブザーバの使い時は色々あります。ある集約全体における更新日時を記録する場合です。LaravelのEloquentにはタイムスタンプを自動記録する機能があり、あるレコードを更新した際にそのレコード内の特定のカラム(デフォはupdated_at)に日時を記録してくれます。これだけでも便利なのですが、これだけではシステムの要求を満たせない場合もあります。あるユーザの情報が複数テーブルに分割されており、いずれかの情報が更新された時にユーザ情報が更新されたとし、その更新日時を記録する必要がある、という場合です。具体的に次のER図のテーブル構成があるとします。ブログへの投稿かコメントを行った時にユーザの最終発言日時を記録する、とします。このような時、次のObserverを作ると要求を満たせます。}}他にもログ取り、検索テーブル用の同期、削除や復元の連鎖など使うと楽になる場面がいくらかあります。モデルのコードが膨れ上がらないための分割としても使えます。deniedで弾かれることがあります。この記事ではLaravelにおけるこのエラーの防ぎ方を書きます。hogehoge(root以外が触れられるべきでないローカル領域に触れる処理とか)とwebサーバによるpublic/index.php(webページの表示)の二つが走るものとします。この前提の鬼門はrootユーザ製ログファイルにapache等のwebサーバがログを追記しようとする場合です。デフォルトでは次のようなファイルができあがり、webサーバに書き込み権限がないままwebサーバがログを書こうとしてこけます。laravel-2019-10-01.logいくつか試した対応策で私的に最も有効なのは次です。],];コードのコメントにある通りwhoamiコマンドからプログラムの実行ユーザを得て、名前別にログファイルを分けるやり方です。これを用いると次のようにログファイルが分割され、権限による問題が起きなくなります。sortコマンドがいくらか役に立ちます。用いて各行が時系列順に結合された結果を見れます。いくらか、というのはスタックトレース等の複数行に渡るメッセージが壊れるからです。残念ながらこれの対策は個別にファイルを見るぐらいしか見つけられていません。denied対策です。状況によっては有効かもしれません。一つ目はログファイルのデフォルトアクセス権限を変えるやり方です。],デフォルトのアクセス権限を誰でも読み書き可にすることでroot:rootなログファイルがあってもwebサーバから追記できます。誰でも既存のログを破壊できる点が気になって没にしました。二つ目はPHP組み込み関数get_current_userを使うやり方です。],一見shell_exec(‘whoami’)と同様の結果を得られそうな関数名ですが異なる動作をします。get_current_userは現在のPHPスクリプトの所有者の名前を返します。hogeとするとget_current_userはcplabを返します。プロセス所有者はrootなので生成されるログファイルの所有者はrootです。artisanとwebページを分ける意味では適していますが実行ユーザ基準でログを分離するwhoamiの方がより安全と考えて没になりました。【Laravel】6.0.4リリースとLaravel製APIテストの拡張Laravel6.0.4がリリースされました。laravel/framework機能の追加は次の通りです。(#29987)自分にとって特別な追加はTestResponse::assertJsonPath()です。これのおかげでAPIのミドルウェア込みテスト(疑似的なリクエストを投げて、ルーターとコントローラを通して、レスポンスを返してもらって、レスポンスをチェック)をより簡潔に必要な分だけ作れる様になりました。LaravelのTestCaseではAPI用にJSONレスポンス用のassertが用意されています。用意されていたのは大規模にならざるを得ないメソッドや素朴すぎるメソッドです。assertExactJsonがあります。これは完全一致のJSONを期待するassertで次のように使います。],]);これはこれで便利なのですが、細かい単位でテストし難いです。同じコントローラメソッドを繰り返しテストすると微妙な差分の期待するJSON定義が膨らみます。言えば、何をテストしたいのかぱっと見分かりません。Laravel6.0.4で追加されたassertJsonPathはこれを解決します。次のコードの様に、JSONの特定のパスについてのみassertをすることで簡潔に必要な分だけ検査をできます。先述のassertExactJsonをassertJsonPathに書き直すと次のようになります。]);ちなみにJSONレスポンスを期待する疑似リクエストを投げる時のコードは次のようになります。postのみならずput等HTTP2.0で定義されるメソッドにも対応しています。scopeHogehoge()の使い分けLaravelのEloquentにはクエリビルダでチェーンを組むための命名規則に従ったメソッド作成方法があります。scopeHogehoge()とするとModel::hogehoge()とするとクエリビルダが走ります。この状態のまま次のようにチェーンを組めるのが利点です。User::hogehoge()->orderBy('fuga')->limit(30);検索などでクエリの一部を使いまわしたい時などとても助かります。助かるのですが、この手法はモデルにも継承元であるEloquentにも記述されていないメソッドを呼び出しており、IDEのヘルパが効かず、警告も出力されます。次のようにコメントを記述することで対策できますが、コメントを経由して改めてscopeHogehoge()を検索する必要があります。}}クエリが増えるにつれどんどんコメント→実際の記述と追うのが面倒になりだします。自分の知る使えそうな小技は二つです。一つはコメントの長大化の弊害がありますが次のようにコメントすることです。@seeはによってIDEはジャンプができる様になります。PhpStormならCtrl+Bです。}}もう一つはstaticなクエリビルドメソッドを作ることです。Model::からクエリビルドする時はEloquentクラス中の次のメソッドが呼ばれています。これを使うことで任意のクエリをグローバルスコープ等欠けさせることなく使えます。staticなのでクエリビルド用の別クラスを用意することも簡単です。}...}次が例です。再利用するあてのないメソッドならあと腐れなくstaticにできます。このstaticメソッドでビルダーを返せば、後にクエリビルド用のメソッドチェーンを続けることもできます。Playerに頻繁にクラッシュする不具合が発生。現在修正済みで公開待ち状態。