チャットディーラーの高速開発を支えるLaravel / phpkansai 2018 ChatDealer Rapid Development with Laravel

の高速開発を支える Laravel 株式会社ラクス坂田晃平 PHP カンファレンス関西 2018

自己紹介 • 名前：坂田晃平 • 所属：株式会社ラクス – メールディーラーとチャットディーラーの開発を担当 •
経歴： – 2016 年新卒入社（3 年目） – PHP の使用歴も 3 年目 • メールディーラー：ノンフレームワーク • チャットディーラー：Laravel 1

• はじめに • チャットディーラー（ChatDealer）とは • なぜ Laravel を選択したか？ • Laravel
で良かったこと • Laravel で困ったこと • まとめ今日話すこと 2

はじめに 3

10 年以上 PHP でノンフレームワークで開発・運用されてきた主力サービス（メールディーラー）の開発チームが、新規に姉妹サービス（チャットディーラー）を立ち上げる際に Laravel を選択をしました。開発期間半年というスピードが求められる中で、チームが Laravel
に抱いた理想と現実、また、Laravel (Blade) と Vue.js の組み合わせにより発生した脆弱性への対応など、Laravel での新規サービス立ち上げの経験を具体的にお伝えします。＜セッション概要＞より 4

5 https://www.maildealer.jp/products/ メールディーラー（MailDealer）とは • 問合せメールを一元的に管理・共有するメール対応サポートツール（SaaS）

• 2001 年にサービス提供開始 • 4,000 社以上の導入実績 • メール共有・管理システム市場で 9 年連続
シェア No.1 6 メールディーラー（MailDealer）とは

• 2001 年にサービス提供開始 • 4,000 社以上の導入実績 • メール共有・管理システム市場で 9 年連続
シェア No.1 • PHP でノンフレームワークで開発 7 メールディーラー（MailDealer）とは

• PHP 4 時代にサービスの土台を開発（参考） PHP 4.0 リリースが 2000/05/22 •
長期間改修されてきたソースコード – ソースコードの構成が機能ごとにちぐはぐ – ビューとロジックが分離されていない – リクエストパラメータの受け渡しが煩雑 – バリデーションが煩雑 – etc… • メンテナンス性の低下 8 課題

• PHP 4 時代にサービスの土台を開発（参考） PHP 4.0 リリースが 2000/05/22 •
長期間改修されてきたソースコード – ソースコードの構成が機能ごとにちぐはぐ – ビューとロジックが分離されていない – リクエストパラメータの受け渡しが煩雑 – バリデーションが煩雑 – etc… • メンテナンス性の低下 9 課題課題感をもつ開発チームが新サービスを立ち上げ！

チャットディーラー（ChatDealer）とは 10

サービス概要 • Web ページに専用スクリプトを埋め込んで利用する Web チャットシステム（SaaS） • 本文 11
https://www.chatdealer.jp/products/

サービス概要 • Web ページに専用スクリプトを埋め込んで利用する Web チャットシステム（SaaS） • 本文 12
https://www.chatdealer.jp/products/

技術スタック • 言語、フレームワーク – PHP 7.1、Laravel 5.5 – Node.js、Express、Socket.IO •
開発環境 – PhpStorm、Jenkins、Redmine、GitLab、 Mattermost • インフラ – 仮想基盤(オンプレ)、nginx、Apache、 PostgreSQL 9.6、Redis 13

開発チーム構成 • プロジェクトマネージャー • エンジニア – toB 向けバックエンド (PHP)：３名 –
toC 向けフロントエンド (Node.js)：３名 14

開発スケジュール 15 2月 3月 4月 5月 6月 7月要件定義 2017年
開発基盤整備設計実装・単体テストシステムテスト β版ﾌｨｰﾄﾞﾊﾞｯｸ改修 β版リリース本番リリース

なぜ Laravel を選択したか？ 16

はじめに • 新サービスの立ち上げに際しての課題 – 短納期（6 ヶ月） • 実装の期間は実質 2 ヶ月
• 開発効率の向上必須 – レガシーからの脱却 • レガシーシステムの課題を解決 • 開発チームはフレームワークを使っていない 17

18 レガシーシステムでの課題（再掲） • PHP 4 時代にサービスの土台を開発 • 長期間改修されてきたソースコード – ソースコードの構成が機能ごとにちぐはぐ
– ビューとロジックが分離されていない – リクエストパラメータの受け渡しが煩雑 – バリデーションが煩雑 – etc… • メンテナンス性の低下

• 実装工数の短縮 • メンテナンス性の向上 – MVC モデルによるコードの分離 – コーディングルールやファイル構成の標準化 –
リクエスト情報の管理方法の標準化 – 一般的な脆弱性への対策 19 フレームワークに期待すること

フレームワーク選定 • フレームワークに期待する要件は次の2点 – 長期サポート – 機能性 20

選定条件：長期サポート • すぐにサポート切れしてはメンテナンス性が悪くなる • 長期サポートされる条件を検討 – 使用者数が多く、人気がある – 活発なコミュニティ
– LTS (Long-Term Support) を宣言している 21

選定条件：長期サポート • シェア率が高い人気のフレームワークを調査 – 調査段階では、日本では CakePHP に続き Laravel がシェア 2
位だった – 世界では Laravel が圧倒的に使用されている – Laravel のシェア率の伸びが一番大きい – コミュニティが活発 22

選定条件：長期サポート https://trends.google.co.jp/trends/explore?date=today%205- y&q=Laravel,CakePHP,Symfony,CodeIgniter,FuelPHP 23 • Google トレンドでの比較 Laravel は一番人気があり、上昇し続け
ている

選定条件：長期サポート • Laravel は LTS に対応 – Laravel 5.1 より
LTS に対応した – バグフィックスは 2 年間、セキュリティーパッチの提供は 3 年間 – 新サービス開発開始の半年後に新たな LTS バージョン (5.5) がリリース予定 24

選定条件：機能性 • 基本機能 – ルーティング – テンプレートエンジン (Blade) – 扱いやすいバリデーター
– 認証、セッション管理、エラーハンドリング等の基本機能 – 一般的な脆弱性への対策 25

選定条件：機能性 • 便利機能やライブラリを調査 – マイグレーション – ページネーション – 様々なミドルウェアやサービスと連携できる •
Redis でのキャッシュ管理など – 主要なライブラリが含まれる • Bootstrap, jQuery, Vue.js など – ユニットテストの作成が容易 • PHPUnit をサポート 26

フレームワーク選定のまとめ下記の点から、新サービスのフレームワークに Laravel を採用する事となった • 長期サポート – LTS バージョンがある
– 一番人気で、今なお人気上昇中 – コミュニティも活発 • 機能性 – フルスタックフレームワークであること 27

Laravel で良かったこと 28

Laravel で良かったこと • オールインワンでスピード開発に向いていた • 簡単設定でどんなものにも繋がる • 標準ライブラリが使いやすい • ドキュメントが充実していた
29

30

オールインワンでスピード開発に向いていた • 準備コストが削減できたので、ロケットスタートを決めることができた – フレームワークの標準機能ルーティング、Middleware、DI、バリデーション、テンプレートエンジン (Blade)、バッチ処理 (Command)、
マイグレーション、デバッグ、クエリビルダ、ページネーション、セッション – ライブラリ、ミドルウェア・サービスとの統合 Composer、Bootstrap、jQuery、Vue.js、PostgreSQL、 Redis、PHPUnit 31

32

簡単設定でどんなものにも繋がる • チャットディーラーで利用しているミドルウェアの一例 – PostgreSQL – Redis – Postfix
いずれも、接続のための仕組みは準備されており、簡単設定で繋がった 33

34

標準ライブラリが使いやすい • ルーティング – URL とコントローラの紐づけが直観的に書けてわかりやすかった 35

標準ライブラリが使いやすい • Middleware – HTTP リクエストをフィルタリングする機能 – リクエスト処理の事前チェックや事後処理を Middleware に実装、適用したいルーティング設
定を group メソッドで囲うだけ – 認証処理などを Middleware に実装にしたことで、ビジネスロジックに専念できた 36

標準ライブラリが使いやすい • DI – メソッドインジェクション機能が便利 – タイプヒントするだけで、メソッドの引数にオブジェクト注入される 37

標準ライブラリが使いやすい • バリデーション – Request クラスにバリデーションルールを追加し、コントローラーメソッドでタイプヒントするだけ – コントローラーメソッドに、バリデーション処
理を実装をする必要がなくなった 38

• バリデーション – バラエティ豊富なバリデーションルール標準ライブラリが使いやすい 39 https://readouble.com/laravel/5.5/ja/validation.html

標準ライブラリが使いやすい • テンプレートエンジン（Blade） – 覚えることが少なく、なじみやすいシンタックス – Blade ファイルは PHP
ファイルにコンパイルされ、変更が無い限りはコンパイルした PHP ファイルを呼び出すので軽量（らしい） – 他のテンプレートエンジンとくらべ制約が緩く、 @php ディレクティブで PHP コードの記述もできる 40

標準ライブラリが使いやすい 41 • テンプレートエンジン（Blade） – ノンフレームワークサービスの場合

• テンプレートエンジン（Blade） – Laravel の場合標準ライブラリが使いやすい画面ごとに切替えたいコンテンツを @yield ディレクティブで指定する 42
@section ディレクティブ内に挿入するコンテンツを記述する

標準ライブラリが使いやすい • バッチ処理（Command） – cron レコードは 1 件、実行スケジュールを PHP 内に記述できるようになり管理が楽になっ
た 43

• バッチ処理（Command） – ノンフレームワークサービスの場合標準ライブラリが使いやすいバージョンアップを重ねていく内に cron レコードが増えていく 44

• バッチ処理（Command） – Laravel の場合 • cron は 1 レコードのみ
• 実行スケジュールを PHP で記述できる標準ライブラリが使いやすい 45

標準ライブラリが使いやすい • マイグレーション – DB の移行パッチの適用管理が楽になった 46

• マイグレーション – ノンフレームワークサービスの場合 – Laravel の場合アプリケーションのバージョンより、新しいバージョンをファイル名に含むパッチファイルを実行
コマンドを実行するだけで、マイグレーションファイルの中から未実行のファイルのみを自動実行ロールバックも可能 47 標準ライブラリが使いやすい

標準ライブラリが使いやすい • デバッグ – Laravel をバージョンアップ (5.4→5.5) 後、デバッグモード時のエラーページの情報量がすごかった
– デバッグ時間の大幅短縮することができた 48

標準ライブラリが使いやすいエラーメッセージスーパーグローバル、環境情報などスタックトレースエラー発生箇所 49 • デバッグ

50

ドキュメントが充実していた • 必要な情報が公式ドキュメントとして準備されていた 51 http://laravel.jp/

ドキュメントが充実していた • 公式ドキュメントが日本語化されていた 52 https://readouble.com/laravel/5.5/ja/

Laravel で困ったこと 53

Laravel で困ったこと • Blade (SSR) + Vue.js での脆弱性 • Vue.js
は思ったより難しかった 54

Blade (SSR) + Vue.js での脆弱性 • Laravel 標準の認証画面に XSS の問題
– ある時のリリースノート > In Laravel 5.6.9 and Laravel 5.5.37, a potential XSS > vector was patched in the default Bootstrap > scaffolding that ships with laravel. > Laravel 5.6.9 と 5.5.37 では、標準のスキャフォール > ディングで、潜在的な XSS の可能性が修正されました。 https://laravel-news.com/laravel-5-6-9 56

• Laravel 標準の認証画面に XSS の問題 – ある時のリリースノート > In Laravel
5.6.9 and Laravel 5.5.37, a potential XSS > vector was patched in the default Bootstrap > scaffolding that ships with laravel. Laravel 5.6.9 と 5.5.37 では、標準のスキャフォールディングで、潜在的な XSS の可能性が修正されました Blade (SSR) + Vue.js での脆弱性 https://laravel-news.com/laravel-5-6-9 57 XSS なんて怖いわぁ…。標準のスキャフォールディングは使ってないし関係ないっぽいけど。でも、どこで XSS になってるんやろ？

• Laravel 標準の認証画面に XSS の問題 – ある時のリリースノート > In Laravel
5.6.9 and Laravel 5.5.37, a potential XSS > vector was patched in the default Bootstrap > scaffolding that ships with laravel. Laravel 5.6.9 と 5.5.37 では、標準のスキャフォールディングで、潜在的な XSS の可能性が修正されました Blade (SSR) + Vue.js での脆弱性 https://laravel-news.com/laravel-5-6-9 58 XSS なんて怖いわぁ…。標準のスキャフォールディングは使ってないし関係ないっぽいけど。でも、どこで XSS になってるんやろ？実は、、、関係あった！（調べてよかった…）

Blade (SSR) + Vue.js での脆弱性 • サーバーサイドレンダリング (SSR) と Vue.js
との組み合わせで起こりうる XSS – Blade との組み合わせに限らない – 実は Vue.js 特有というわけでもない • AngulerJS ではもっと前（2014 年くらい）から話題になっていたらしい https://havelog.ayumusato.com/develop/security/e593- mixins_server_template_and_angular.html 59

• SSR と Vue.js の組み合わせで起こる XSS サーバーでの処理ブラウザでの処理 Blade (SSR)
+ Vue.js での脆弱性 <div id="app"> {{ $name }} </div> sample.blade.php Blade で処理 $name = “{{ alert(‘XSS') }}” <div id="app"> {{ alert('XSS') }} </div> <div id="app"> {{ alert(‘XSS’) }} </div> Vue.js が処理 <div id="app"> </div> 60 {{ … }} の中のスクリプトが実行される！処理済みのHTMLデータレスポンス送信ブラウザが読込

• SSR と Vue.js の組み合わせで起こる XSS サーバーでの処理ブラウザでの処理 Blade (SSR)
+ Vue.js での脆弱性 <div id="app"> {{ $name }} </div> sample.blade.php Blade で処理 $name = “{{ alert(‘XSS') }}” <div id="app"> {{ alert('XSS') }} </div> <div id="app"> {{ alert(‘XSS’) }} </div> Vue.js が処理 <div id="app"> </div> 61 {{ … }} の中のスクリプトが実行される！処理済みのHTMLデータレスポンス送信ブラウザが読込

• SSR と Vue.js の組み合わせで起こる XSS – Vue.js で処理される領域にユーザー入力の文字列を
SSR で埋め込むと危険 – “mustache injection” と（個人的に）呼んでる {{…}} ← これを Mustache 構文と呼ぶことから – 知らなかったら普通に作ってしまいそう Blade (SSR) + Vue.js での脆弱性 62

• SSR と Vue.js の組み合わせで起こる XSS – Vue.js で処理される領域にユーザー入力の文字列を
SSR で埋め込むと危険 – “mustache injection” と（個人的に）呼んでる {{…}} ← これを Mustache 構文と呼ぶことから – 知らなかったら普通に作ってしまいそう • 知らなかったし、実際作ってしまっていた Blade (SSR) + Vue.js での脆弱性 63

Blade (SSR) + Vue.js での脆弱性 • mustache injection 対策案1 (不採用)
– “{” や “}” を HTML エスケープ • 効果なしサーバー側でエスケープしても、Vue.js が処理する時にはブラウザによってもとに戻されてしまっている 64 サーバーでの処理 <div id="app"> {{ alert('XSS') }} </div> <div id="app"> {{ escapeMustache($name) }} </div> sample2.blade.php ブラウザでの処理 <div id="app"> {{ alert(‘XSS’) }} </div> $name = “{{ alert(‘XSS') }}”

– “v-pre” ディレクティブの利用 • Laravel のスキャフォールディングでの対策 • 効果は実証されている • 結果：対象箇所が多すぎる・新しく書く時も必ずつける必要・忘れそう 65 ブラウザでの処理 <div id="app"> <span v-pre>{{ alert(‘XSS’) }}</span> </div> v-pre の要素内は Vue.js で処理されない

– “{{” や “}}” の文字間に半角空白を挿入する • “{” や “}” のHTMLエンティティ表現に対しても同様に処理が必要 ↓ • “{”、“{”、“{” のうち 2 つの組み合わせ • “}”、“}”、“}” のうち 2 つの組み合わせ • さらにそれらが連続している場合でも漏れなく空白を入れる必要がある 66 サーバーでの処理 {{{&#x7b{ … }&#x7d}}} 危険な文字列： { { { { { … } } } } } 無害な文字列：

Blade (SSR) + Vue.js での脆弱性 • mustache injection 対策案 (3)
– “{{” や “}}” の文字間に半角空白を挿入する • “{” や “}” のエンティティ表現に対しても同様に処理が必要 ↓ • “{”、“{”、“{” のうち 2 つの組み合わせ • “}”、“}”、“}” のうち 2 つの組み合わせ • さらにそれらが連続している場合でも漏れなく空白を入れる必要がある 67 サーバーでの処理 {{{&#x7b{ … }&#x7d}}} 危険な文字列： { { { { { … } } } } } 無害な文字列： $replacementMap = [ "{{" => "{ {" , "{{" => "{ {" , "{{" => "{ {" , "{{" => "{ {" , "{{" => "{ {" , "{{" => "{ {" , "{{" => "{ {" , "{{" => "{ {" , "{{" => "{ {" , "}}" => "} }" , "}}" => "} }" , "}}" => "} }" , "}}" => "} }" , "}}" => "} }" , "}}" => "} }" , "}}" => "} }" , "}}" => "} }" , "}}" => "} }" ];

Blade (SSR) + Vue.js での脆弱性 • mustache injection 対策案4 (採用)
– “{{” や “}}” の文字間に半角空白を挿入する – いつやるか？ • 出力時 ⇒ “v-pre” 使用と同様の問題。対象箇所が多い・忘れそう • 入力時 ⇒ Middleware ですべてのリクエストパラメータを処理すれば確実 – 根本的な解決は…(^ω^; • SPA 化しかない？ 68

Vue.js は思ったより難しかった 70 • 開発を始める前は… – チームメンバーはみな jQuery に慣れ親しんでいる（特にベテラン）
– Vue.js は「学習コストが低い」という前評判 – 軽く公式のガイドを見てもそんな印象 • 内容を表示させたい場所に `v-bind:` ってつければ表示される！ • しかもモデルの値を変えたら自動で反映される！ – 確かに簡単そうだ（と思ってしまった） • そのまま開発に突入

Vue.js は思ったより難しかった 71 • 開発を始めてみると… – Vue インスタンスが紐づいた要素内の子要素を別の Vue
インスタンスで制御したい – 離れた場所にある別々の要素を同じ Vue インスタンスで制御したい – jQuery や Bootstrap のライブラリと一緒に使いたい – モデルの値を変えてるはずなのに反映されない

インスタンスで制御したい – 離れた場所にある別々の要素を同じVueインスタンスで制御したい – jQuery や Bootstrap のライブラリと一緒に使いたい – モデルの値を変えてるはずなのに反映されないいったいどうすればいいの…？

インスタンスで制御したい ⇒ 内部の要素はコンポーネントを作ってそれで置き換えましょう – 内部の要素に `v-pre` を付けてもできるけど… – 離れた場所にある別々の要素を同じ Vue インスタンスで制御したい ⇒ コンポーネントにすれば再利用できます

Vue.js は思ったより難しかった 74 • 開発を始めてみると… – jQuery や Bootstrap のライブラリと一緒に使
いたい ⇒ ラッパーコンポーネントを作れば比較的楽に統合できます – モデルの値を変えてるはずなのに反映されない ⇒ 配列やオブジェクトの要素を変更する場合は特別なやり方があるので注意！

Vue.js は思ったより難しかった 75 • jQuery 脳からのパラダイムシフトが必要？ – 「jQuery でなら作り方わかってるのに」 –
利き手でない方の手で字を書くかのよう… – 結局慣れるしかない • jQuery 系ライブラリとの相性 – 仮想 DOM から DOM への変更が実際に反映されるのを待つ必要あり – ノウハウの蓄積

Vue.js は思ったより難しかった 76 • 「学習コストが低い」とは言え、やっぱりちゃんと勉強しないとだめだった – 最近は日本語で読める入門記事もどんどん増えていて学習しやすくなっている印象 •
少し複雑なことをしたいときはコンポーネント化が必須 – コンポーネントの考え方が分かりにくいとの声もあるが – そこは勉強してもらうしかない

まとめ 77

まとめ • フレームワークがスピード開発に役立った – ミドルウェアとの連携設定 – MVC の考えに沿ったソース配置 – ビジネスロジックへの集中ができた！
• とくに Laravel で良かったこと – 豊富な機能 – 日本語公式ドキュメント – 活発なコミュニティ • 脆弱性への対応も早かった 78

まとめ • Vue.js との組み合わせには注意 – 脆弱性への対応を後からするのは大変 • Vue.js もちゃんと勉強しよう •
Laravel の豊富な機能を使いこなせない – アイデアをぜひ教えてほしいです！ 79

PHP エンジニア募集中 www.facebook.com/rakus.career 80

チャットディーラーの高速開発を支えるLaravel / phpkansai 2018 ChatDealer Rapid Development with Laravel

チャットディーラーの高速開発を支えるLaravel / phpkansai 2018 ChatDealer Rapid Development with Laravel

More Decks by 坂田晃平

Other Decks in Technology

Featured

Transcript