【PHP】Laravel【フレームワーク】 Part.3
■ このスレッドは過去ログ倉庫に格納されています
テンプレ追加修正お願いします
Laravel
ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
日本語
http://laravel.jp/
書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク！] (Software Design plus)
※前スレ
【PHP】Laravel【フレームワーク】
https://medaka.5ch.net/test/read.cgi/php/1503683914/
【PHP】Laravel【フレームワーク】 Part.2
https://medaka.5ch.net/test/read.cgi/php/1556417229/
amazonへのリンクが邪魔をしてスレッドを建てられなかったので外しました。 ずっと静観してたけど、ひとつだけ。
俺はおっさんじゃなくおばさんだよ。失礼な！ >>381
13日の金曜日は危険だからジェイソンに気を付けろって話だろ 外注選定でここ数年Laravelばかりやってる奴はまずNGにする。
Laravelでしか物を作れないから。 Laravelでしか物を作れないってどういうこと？ >>384
throttleエラーも直せなかったおじさんまだ生きてたの？
>>56と>>58への返信早く書いてよ。 >>384
めちゃわかる symfonyやってる人ってLaravelやCodeigniterとかもいけるけど
Laravelやってる人って他のフレームワークは使えないこと多い このフレームワークは比較するならsymfonyじゃね？
Eloquentとか言うORMまがいの機能持った最強フレームワークが中身がスカスカなORM機能に
無意味に好かれまくってグダグダな機能を実装するご都合主義のフレームワークだし
DB要素あり認証要素もふんだんに盛り込み何でPHPフレームワーク界で人気なのか笑いの種になるその出来の悪さと
色々と重なり合う点が多いと思うけどｗ 今度はSpringおじさんか
外注選定するときにフレームワークも指定しろよ
phpならLaravelのシェアがトップなんだから指定しなきゃLaravel製になることくらい想像できるだろ >>389
だからLaravelばっかりやってるやつは除外していると言ってるだろ >>390
このスレの人たち技術レベル低いからあまり相手にしないほうがいいですよ すまん誰か>>388について解説してくれ
さっきから何度も読み直しているが理解できない ベトナムに開発を任せると、漏れなくLaravelで作るのでつらい。
保守段階になってLaravelのソースなんぞ見たくない。 そこまでLaravelを嫌う理由ってなんだ
具体的にどこのどういう部分がダメでどういう形だったらいいと思ってるのよ >>393
なんでLaravel嫌いなの？理由は？ やっぱり外注にLaravel頼んでるじゃん
↓
33 nobodyさん sage 2020/01/24(金) 13:35:52.65 ID:???
>>32
結局、429出なくなった。
file_get_contentsしていた箇所をcurlに置き換えただけで。
しかし、Laravelには関わりたくねーな。
ベトナム辺りに流すとLaravel使いたがるので困る。 >>384
なんでわざわざLaravelスレに来たの？ 親にlaravelを殺されたんじゃないかと思うくらいの執着心 >>395
スレを遡って読んでみた限りだと、ThrotlleRequestsクラスが出すエラー（時間内最大リクエスト数の制限）の直し方が分からなかったのがトラウマらしい。 >>399
え？それって結構初歩的な話では・・・・ >>396
だから除外しているって言ってるだろ
お前らって日本語理解しているか？
この程度も理解できないようじゃお前らLaravelの簡単なことさえもわからなくて悩んでるんじゃないのかｗｗ
まあLaravel使うやつはこの程度か・・・ 話を戻すとjsonは脆弱性が多いので使わないほうがいい
csvやxmlについては実装次第ということか >>394
Laravelは何も悪くない。
オフショアにやらせると速攻で作ってくれるので。
それしか知らない奴が問題。
メール送るだけのバッチまでLaravelを通しやがる。メモリ食うだけだ。
だから、どこぞのエージェントが回してくるスキルシートのアピール欄に
「Laravelならお任せください！」とか書いてあると、その段階でNG。 >>403
Laravelそのものが何も悪くないならお前スレチすぎだろ
ただの仕事の愚痴じゃねえか >>404
これが仕事の愚痴に見えるようならもう少し勉強してから俺にレスしてくれ メールバッチごときのメモリ使用量を気にする環境ってなんなんだよｗｗ
まあ塵も積もれば山となるのかもしれないけどさ お前らってLaravelは使っているだろうけど
LumenとかLaravel Zeroとかは使っているの？ >>403
「WordPressならお任せください」
「CakePHPならお任せください」
「Symphonyならお任せください」
「Laravelならお任せください」
「PHPならお任せください」
「Rubyならお任せください」
「Javaならお任せください」
「Nodejsならお任せください」
どれ選ぶ？ CodeIgniter&FuelPHP「僕らは・・・・・・」 >>405
反論するならそこじゃないだろ
Laravelが何も悪くないならお前はスレチ >>410
Laravel悪いぞ メール送るだけでメモリ空メモリくりだ >>411
メモリ空メモリくりって何の誤字？
まぁそれはともかく、実装の責務だったって話は無いの？
昨日まで「JSONは脆弱だ」と騒いでた人たちいるけど、実際には実装が悪くてJSON固有の話ではなかったように、
それは本当にLaravel固有の問題なの？
誰が実装したの？
実装に問題は無かったの？
メールドライバは何を使っているの？
仮にメールドライバを一般的なSMTPと仮定したとして、SwiftMailerの問題だったりしない？
Laravelはメール送信にSwiftMailerっていうライブラリを使っているんだけど、SymfonyもSwiftMailerを使っているから、実はSymfonyに変えてもメール送信に使うメモリ量は変わらなかったりしない？ >>412
いやJSONは実装ではなくフォーマット事態に脆弱性あるでしょ laravelのjson処理には脆弱性あるよ
でもそれはアップデートすれば治るよね？ >>412
つまり他人を疑う前にまず自分を疑いましょうって話だわな
このエッセイ思い出した
https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/%E3%82%A8%E3%83%83%E3%82%BB%E3%82%A4/%E4%BB%96%E4%BA%BA%E3%82%88%E3%82%8A%E3%81%BE%E3%81%9A%E8%87%AA%E5%88%86%E3%82%92%E7%96%91%E3%81%86/
一部抜粋
> もちろんシステムソフトウェアにもバグはあるものですが、責任を押し付けたがる人が期待するよりは、はるかに少ないと言えます。
> 何か問題が起きた時には必ず真っ先に自分の書いたコードのバグを疑うことにしています。自分のコードを徹底的に調べて、それでもバグが見つからなかった時、初めてコンパイラのバグを疑い、スタック汚染を調査します、たとえば laravelって組み込みlinuxの案件でしか使ったことないな
シェア的にはNo1のはずだけど日本ではまだCakePHPのほうが上なのかな >>416
laravelは脆弱性が多すぎるので日本ではあまり使われていない
日本だとsymfonyかcakeが主流 >>415
いや、少なくともJSONに限っては深刻な脆弱性があるよ。
俺も自分の実装を見直したんだけど、やっぱり実装の問題ではなかった。 ※ この期に及んで具体例無しで脆弱脆弱言ってるやつは荒らしとみなして触らないこと。 >>419
だからおれが>>300で具体例挙げたじゃん >>420
>そして万が一追加チェックを忘れてしまうと、実装によっては脆弱性になりかねない。
>実装によっては
んでLaravel固有の具体例は？ 誰かLaravelのissueにjsonの脆弱性について質問してこいよ
これで決着つくだろ LaravelがMySQLと相性悪いと感じるの俺だけ？
DBサーバがいるわけではなくてLaravelとDBが同一サーバにいるんだけどなぜか接続が切れることが多い
誰が悪いのか調べるために実験したんだが
・素のphpでDB接続→接続は安定
・cakeでDB接続→接続は安定
・codeigniterでDB接続→接続は安定
・symfonyでDB接続→接続は安定
・laravelでDB接続→５分に1回の割合でコネクションが切断される
laravelだけ通信が切断されることがあった。同じ系列であるmariadbでも
上の実験を試してみたが結果は同じだった
laravelで接続を安定させるために変更すべきオプションとかあれば教えてください フレームワークの設定はDBのユーザ名とかDB名とか変更したぐらいで
その他の設定はいじくってないデフォルト設定という認識でＯＫ？ 考えられるとしたらコネクションプーリングのkeepaliveみたいな役割する間隔の
設定値だけどlaravelってデフォルトでコネクションプーリング動くんでしたっけ？ >>427
そもそもphpとmysql間でコネプー維持するもんなの？
javaでイベント駆動なら分かるけど、phpでイベント駆動なんて聞かないし、
リクエスト終了時にコネクションも切断するでしょ。 自分が今まで常駐したところだとPHPでもコネプーしているシステムが多かったですね
DBの接続切断処理に対するサーバ負荷を下げる目的でやっていたみたいですが お前らおすすめのLaravelチュートリアルって何？ めずらしくこのスレ議論が白熱しているな
いつもこのぐらい白熱していればいいんだがな >>433
半分くらいは荒らしみたいなもんだったけどな >>435
でもお前jsonの脆弱性答えられなかっただろｗ >>435
お前がjson脆弱性君か早くjsonの脆弱性について答えてくれよｗ >>408
ExpressじゃなくてNode.js？ >>424
なんかそれこのスレで散々言われてたけどVPS or VirtualBox+CentOS7+Nginx+Laravelでやってる俺はそういう現象に見舞われた事全くないんだけど
どんな環境でやってんの？ 未だにDockerを使わずVBで鯖構築してる奴いるのか 逆にDocker使ってるならMySQLとLaravelの相性云々言う前にDockerってキーワード出てこないとおかしくない？ >>418
だからさあ、具体的な内容書けよ。
仕様の脆弱性なんだよな。
XMLの実体参照の問題みたいなのでもいいから示してみなよ。 jsonおじさん呼び込んだそもそもの原因である>>263って結局どうなの バカみたいに伸びてると思ったら外部JSONが汚染されてるからどうのこうのって話？くだらな、スレチもいいとこじゃん 「Laravel得意です！」のアピールはやめとけというのがこのスレの結論だな。 >>444
jsonを返すだけなのでフレームワークの相性は関係ない >>447
全然違うだろ 仮にapiサーバとして動かす場合はLaravelが一番優れている
他フレームワークと違って細かい制御が可能になる webpackを自分でセットアップしなくて済むのはビギナー的には大きい >>450
LaravelMixのこと言ってる？
あれ独立して使える時点でLaravelとの相性は関係なくないか？
そもそも言うほどwebpack自分で設定するか？
vue create か create-react-app コマンド打つだけで雛形用意されるし、そこから追加の設定が必要ならLaravelMixでも変わらない。 >>452
でもそれバックエンドとの結合テストでデバッグする際に毎回サーバーにdistのjsをコピーするって事っしょ？ >>455
ごめん、24歳保育士の彼女と電話してた やめたれｗｗ
>>455だって彼女ぐらいいるよ・・ >>455
つまりLaravelはフロントフレームワークとの相性がかなり良い
他フレームワークと違って細かい制御が可能でビギナーにも優しい >>458
24歳保育士の彼女との電話がなりすましってことは
彼女いるのは嘘なんですか（；ω；） >>460
彼女どころかすでに結婚してるから
ちなみに俺フェラーリに乗っていてコロナ自粛前は
毎日スポーツジムに通ったり映画館や近くの高級店で優雅な朝食を
食べたりしていたな ごめんねレベルが違う話しちゃって 結婚しているはまあいいとして
普段の生活情報いりますかね？ >>465
具体例出せって言われてるのいつ理解するの？ >>462
なんか一般人が必死に考えた金持ちのイメージって感じなんだけど・・・・ HTTPメソッドの使い分けはその操作が安全であるかどうか、べき等であるかどうかで判断するのが原則。
安全→サーバ、特にDBなどの状態を変化させないこと
べき等→その操作を何度行っても結果が同じであること
検索のような安全でべき等な処理はGETが推奨。
要はGETを使う場合はブラウザ側でキャッシュしても問題ないようにしておいてねということ。
POSTはリソースの新規作成など安全でもなくべき等でもない操作に使う。
ただし、クエリパラメータに出したくない項目がある場合や、検索項目がとんでもなく多くてURLが長くなる場合などに、安全でべき等な操作であってもPOSTを使わざるを得ないこともありうる
GETであることの他の利点は、Google検索のようにURLだけでそのまま検索結果の表示ができること
つまりjsonだけで行う通信は脆弱性があるということ × つまりjsonだけで行う通信は脆弱性がある
○ 話は変わるがjsonだけで行う通信は脆弱性がある >>470
× つまりjsonだけで行う通信は脆弱性がある
× 話は変わるがjsonだけで行う通信は脆弱性がある
○ つまりどんなプロトコルだろうとPOSTのような処理には作り方次第で脆弱性を生むリスクがある ①edit画面が呼ばれ、DBから初期データ取得してフォーム要素にセットして表示
⇒ この画面で編集されて[確認]ボタン押されPOST送信される
②confirm画面が呼ばれ、フォームデータを取得しバリデーションして以下２通りの処理に分かれる
その１) ⇒ バリデーションＯＫの場合、確認画面を表示。return view('path.to.confirm', compact('data'));
その２) ⇒ バリデーションＮＧの場合、edit画面に戻しエラー表示。return view('path.to.edit', compact('data', 'error'));
以上のような画面遷移があるとすると
path/to/edit.blade.phpのフォーム要素valueの書き方をどうすべきか迷っています。
DBから取得し、そのままビューに渡すと value="{{$data->hoge}}" 形式で書きます。
edit画面に戻す時にそのまま渡すと配列のため value="{{$data['hoge']}}" こう書くことになります。
なので両方に対応するには value="{{$data['hoge'] or $data->hoge}}" のように書くことで対応できそうです。
でもスマートではないのでedit画面に戻す時は $data = (object)$data; のようにキャストすることで value="{{$data->hoge}}" だけでよさそうになりそうです。
これって他にもっといい方法ありますか？ >>473
6.x で例書くけど今度からはバージョンも書いたほうがいいぞ。
> return view('path.to.edit', compact('data', 'error'));
これが駄目
正解は FormRequest クラスを使う。
https://laravel.com/docs/6.x/validation
どうしてもコントローラーでバリデーションしたければこれを使う。
return back()->withInput();
そして view では old 関数を使う。
<input type="text" name="title" value="{{ old('title', $data->title) }}">
第1引数は前回入力値のname属性名。第2引数はデフォルト値。
https://laravel.com/docs/6.x/requests#old-input Oracle「Laravelもボクが管理するよ」
ってなったら終わりだな FormRequest使うと入力エラーだと入力画面に戻ってoldで入力値が取れるけど、その時にFormRequest内で入力値に追加することってできないのかな
やりたいことは画像アップロード付のFromでエラーで戻った時に正常にアップロード済みの画像は再選択しなくてもいいようにしたいです
画像でエラーが出た時はもちろん再選択でいいです
なので入力エラーの時は入力データに別のキーでアップロード済み画像のフルファイル名と元ファイル名を持たせようかと思ったんだけどうまくいかない そういう用途用のlaravel用ライブラリ誰かが作ってた気がするけど
ライブラリ名が思い出せない すまんな >>477
画像ファイルそのものをpostするのではなくbase64エンコードした画像をpostしちゃえば、ただのstringのやりとりだし簡単に解決じゃね？ つか最初からSPAならそんなこと悩まなくて済むのにね。 こういうのがいるからセキュリティリスクを生むんだよな ■ このスレッドは過去ログ倉庫に格納されています
