【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へのリンクが邪魔をしてスレッドを建てられなかったので外しました。 >>231
DDDとか取り入れる時はEloquentsディレクトリ作ってそこにLaravelの所謂モデルを入れてる
DB取得にだけ使うから呼び方もモデルじゃなくてエロクウェントゥにしてる うちの会社railsからlaravelに主力を変えた symfonyしか知らんけどlaravelはhtmlのformどうやって作るんや
symfonyはformを作成する機能があってややこしいけど >>234
symfonyもlaravelも普通のhtmlのようにform書けるぞ
わざわざFormBuilder的なの使わなくても良い CakeにもあったけどFormBuilder的なの使ってる人居るんだな
生htmlかフロントフレームワークでいいじゃん
却って分かりにくいわ >>232
lazyじゃなくなるな。APIなら大した問題ではないか？ >>235
えそうなの？うちの会社じゃformクラス作ってるが却って分かりにくい気しかしない ぶっちゃけVueとかReactとかと組み合わせて使わないんなら別のフレームワーク使った方がいいんじゃない？
活発なバージョンアップでバンバン互換性が切れてるしLaravelだけの機能で全部賄ってたら古いバージョンにしがみつき続ける事になると思うんよね >>237
ビジネスロジックにフレームワーク絡んでない方が楽できる場合もあるでしょ
まあケースバイケースってやつ 掌田津耶乃って人のlaravel入門ってどうですか？
評判いい？ >>241
やめておくのが吉
ご近所さんながら、玄関前に俺がかったのを置いといてあげるよ できればなぜやめておいたほうがいいのかの理由も知りたいです 掌田津耶乃の本はプログラミング初心者向けでググれば誰かがウェブにおんなじようなこと書いてそうな内容
とりあえず公式ドキュメント（かその日本語訳）読んである程度分かりそうだったり
分からなくてもググって答え見つけ出して解決できる人なら買う必要はない
そもそもこういう入門書ってアプデの度に仕様変更で使い物にならなくなっていくからプログラミングのはじめの一歩ならいいけど基本は公式にあたる癖つけといたほうがいいと思うよ
当たり前だけどタダで読めて更新もされるんだし でもLaravelの日本人コミッターに聞くと絶対
掌田津耶乃が上がるからそれなりに内容はよさそうな気がするが 掌田さんのlaravel本はわかりやすくてよかった
結局ほとんどググったけど、見返すとなるほどと理解が進む。
最初に何をすればさっぱりだった自分はまず掌田さんの本を見て
そかっからググって土日になんとかcrudたてることできました。
これでやっと組み込み基板の部品表管理と論理ソースのgheへのpush環境の
laravel実装が始められる… >>246
はじめの一歩だから本でいいんだよ
いきなり公式ドキュメントを読ませようとするなどうせ挫折する
ググるのは基礎知識があってこそだ >>249
だからはじめの一歩ならいいと書いてあるが？ >>246
Laravel初心者っぽいし最初は本のほうがいいきがするけど はじめの百歩くらいは本でいいだろ公式をあたれる能力が付くのはそれから >>254
ゲーム好きってほどではなく軌跡のためだけにpspやvita,ps3,ps4を買う軌跡のヘビーユーザーとして意見さして頂きたい
あらかじめいうと、ルーファスが一番好きなプレイヤーの意見と考えてくれ。
Cはまずルーファスだと考えている。
身長がまず一つ、モーションで見ると、剣を抜くモーションが完全に閃の3,4のモーションそっくり。
そしてクロウに剣を突きつけるモーションは閃の軌跡2での正体を明かした後ヴィータに突きつけるモーションと同じ
またPVで撤収するときに実はユーシスが見切れている。これは正体が露見するのを防ぐためかと思う。アーツの紫の丸い玉は閃の軌跡3,4のSクラフトで最後紫になる。
PVのモノクロでロイド、リィン、ルーファス、まぁキーアもいるが、でてるのは3人の主人公の別の世界の存在である暗示。ノーマルリィンがでてくるから他の世界のルーファスがでてもおかしくはない。
前作で生きる意味を求めていたルーファス、偽物がゆえに本物になろうとオズボーンに認められようと足掻いていた。しでかしたと言われてめちゃ叩かれてるがひたすらもがいた不器用な男のファンなんだよ。
たぶんラピスも何かの紛い物、本物ではないが存在だが何かを救って救われるルーファスストーリーと期待してます。
仮にも鉄血の筆頭でレクターやクレアのように救われていないあいつは報われて欲しいと思ってるプレイヤーの妄想です。 >>257
お前がな どうした？顔真っ赤にして手が震えって手ているぞ 信者がこれだけLaravelに夢中になるのだから
やはりおれのパンツにリソースをつぎ込めという指摘はきわめて的確なものであったといえよう
更なる増収増益のためにはパンツのステルス化及びカスタマイズモードの採用を提案したい Symfony蹴ってLaravel採用する理由は？ フロントエンドフレームワーク使うんならLaravelの方がいい >>263
なんで？
JSON返すだけならフレームワークの相性なんて関係なくない？ >>264
まさかいまどきJSONでやり取りしてるの？ 天下のGoogle様の場合実はjsonではなくcsv形式でデータをやり取りしていることが多い ここの連中JSONでやり取りしてるのかよｗ
セキュリティ大丈夫か？ サーバー→クライアントがJSONなのであって逆方向の通信にJSON使ってるヤツなんて殆ど居ないだろうし
元々表示させる為のデータが何形式だったからと言ってセキュリティ的には関係ないだろ
クライアント→サーバーがどうかってのならまだしも いやクライアント→サーバーがJSONでも一緒だろw
平文通信ならともかくw >>273
素人にはわからないかもしれないが、サーバ側で不特定の相手からjson形式でデータを受けるときは、セキュリティ上考慮すべきことが増えるんだよ。 Laravel使ってて標準のハッシュ使ってないヤツとかいるの？ >>274
それJSONに限った話じゃないと思うけど？
具体的な問題点と、JSONに代わるセキュアなフォーマットを教えてください。 JSONは悪意あるスクリプトを埋め込まれやすいってのは聞いたことあるな
JSONというよりはJSONのパース処理側に問題があるらしいが >>279
そうそう。json_decodeとかunserializedとかは、改ざんされた入力データで想定外の復元が行われる可能性があるから、信頼されたクライアントでない限りは使わないのが無難(使うなとは言わない)。 >>284
パース時にアンセキュアな問題があるとして、それはどんなフォーマットでも言える。
それはjson固有の問題ではないし、csvだろうがxmlだろうがx-www-form-urlencodeだろうが、パースが甘ければインジェクション系の脆弱性は起こりえる。
逆に、「○○っていうフォーマットを使えばパースは安全」って言ってるならその認識を改めたほうが良い。
>>274 や >>279 「考慮すべきことが増える」とか「悪意あるスクリプトを埋め込まれやすい」って書かれてるけど、肝心の比較対象が書かれていない。 >>287
その前に君の「〇〇っていうフォーマットを使えばパースは安全」
という認識を改めたほうが良いよ >>284
言い過ぎだろ。json仕様に脆弱性はないし（今のとこ）、json_decodeにも脆弱性は見つかってない。
その点でcsvだろうとxmlだろうと、x-www-form-urlencodedだって同じ。（は言い過ぎか） >>288
こどおじには理解できないみたいだからそうせめてやるなよｗ json_decode脆弱性見付かって何回かアップデートかかってるぞ >>289
げ、まる被り（笑）まあ、あとは実装するやつの心がけ次第ということだ。 そうそう。リスク判定できない人はjsonでデータを受け取るなと。 >>291
2009年の脆弱性言われてもなあ。
>>291 json自体の脆弱性の話はしてないんだ。
使い方が悪ければ脆弱性につながりやすいというのを理解できないおこちゃまをどうしてやろうかという話なんだ。 >>295
いや思いっきりJSON固有の話してたのに、急に一般論にして話そらすのやめよう？
話の始まりは >>265 だからそれを見返してね。
「ユーザー入力をJSONでフォーマットするのは危ないですよ」
と
「どんなフォーマットを使ってもユーザー入力は気をつけましょう」
じゃ全然話が違うでしょ >>296
どんなフォーマットだろうが不特定からの入力は、危険だからValidationは必須だよ。
特にjsonとかのデコードを前提とする入力は、さらに慎重なValidationを検討する必要があるよ。
という話をずっとしてるでしょ。 >>297
それなら早く具体的な問題点とJSONに代わるセキュアなフォーマットを挙げてみてよ。
以前のレスにもそう書かれてのになんで挙げないのかな？ 顔真っ赤だな。
jsonはJavascriptとの親和性、csvはExcelとの親和性、XMLは構造の自己記述性とか、それぞれ特徴あって、好きなの選べはいいじゃん。
今回の話はJSONが良さそうに思えるけど、他の選択肢、どんなのあるん？ >>298
たとえばusersテーブルに住所・電話番号を更新させるAPIをつくるとして、
1.住所・電話番号をそれぞれ2つのパラメータとして入力させる場合
住所・電話番号のチェックを行い、それから保存。
2.住所・電話番号を連想配列に格納したものを、json_encodeしたもので入力させる場合（パラメータ1つの場合）
decodeして1と同様のチェックを行う。更に追加でdecode後に要素の過不足が無いかもチェック。それから保存。
という感じで明らかにチェックしなければならないことが増えてしまう。
そして万が一追加チェックを忘れてしまうと、実装によっては脆弱性になりかねない。 >>296
>>265はいまどきJSONでやり取りしているの？って言っただけであって
セキュリティのことは言ってなくないか？ >>298
お前が挙げろよｗ
論破されたからってなりすましは良くないと思います >>300
頓珍漢すぎるでしょ、
content-type ヘッダを application/x-www-form-urlencode で指定して、
その中身は実はjsonだったって場合の話してるの？
そんな実装ありえたにし、そもそもバリデーションを通さないでしょ。
jsonの場合なんだから、content-type は application/json で送って処理させるでしょ。
なんで、jsonって言ってるのに x-www-form-urlencode で送るのｗｗ？ >>300
curlで書くとこういうの想定してる？
curl "http://example.com"; \
-X POST \
-d "key={\"key\": \"param\"}" \
-H "Content-Type: application/x-www-form-urlencoded"
ありえないでしょ…
普通こうだよ。
curl "http://example.com"; \
-X POST \
-d "{\"key\": \"param\"}" \
-H "Content-Type: application/json"
そもそもミドルウェアレベルで弾く話だと思うんだけど、変な例ださないでよ。 >>300
うわーそうきたか
確かにそれは誰も想定できないね
JSON危険厨はやっぱレベルが違う 300の書きたかったことが304のようなことだったとして、結局inputに余計な要素が含まれていないかのチェックは実装によっては必須になるな。 >>307
それいったらJSON関係ないね。
application/json ではそれが必要なのに
application/x-www-form-urlencode にしたら不要になるって話じゃないでしょ。
ちなみに、Laravelの場合は fillable か guarded 設定しないと、
(new User)->fill($request->all())
みたいなことはフレームワークレベルで出来ないから、そっちもあんま関係ないね。 お前らJSONの脆弱性についてまったく理解してないんだな
さっきから的外れなこと言いすぎ
なんだろう俺とお前らの技術レベルの差がありすぎてまともな
議論にならないな >>309
アプリ設計者の想定外のデータが復元されうること以外になんかあったっけ？ だから送信は普通にPOSTするって言ってるだろ
JSON使うのはサーバー→クライアントだけだって >>311
まず EloquentModel の fill メソッドは分かるよな？
もし分からなければ、それについてマニュアル読んでからきてくれ。
例えば >>300 のケースでシミュレータする
usersテーブルにinsertする為のUIがあったとして、
その入力結果をサーバーに送信する際、どんなフォーマットが適切（よりセキュア）なのかが今回の焦点。
>>300 が言っているのは
「パラメータ部分を
-d "user={"address": "東京", "tel": "08012345678"}"
にすると、request()->get('user') をjson_decodeした上で、userの中に余計な属性が無いことを担保しなくてはならない」
と言っている。
（クォーテーションのエスケープは省略するから脳内補完して欲しい）
で、担保する必要があるのは大体、Userモデルに対し fill($request->all()) するようなケース。
（今回だと $casts = ['user' => 'json'] で定義された fill(request()->get('user')) かもしれない。 ）
担保するって言っても $fillable を定義すれば良いだけだが。
そんなフォーマットはありえないから置いておくとして、
実際によくあるのは下の2パターン。
-d "address=東京&tel=08012345678" -H "Content-Type: application/x-www-form-urlencoded"、
-d "{"address": "東京", "tel": "08012345678"}" -H "Content-Type: application/json"
で、余計な属性が無いか担保する場合は前者も後者も変わらない。
逆に、前者の場合は担保が必要なくなる言ってるのはそれはそれで問題だね。
書き方はLaravelで例えたけど言語やフレームワーク変えても書き方が変わるだけで考え方は同じ。 >>312
だからお前が言う普通のPOSTって何だよ
curlで書いてみてくれ なんでcurlなんだよ
URLSearchParamsとかFormDataにappendしたパラメーターをaxiosに渡すような極々シンプルなPOSTだよ なんでcurlでかくのをそこまで拒むの？
本当は俺らの議論についていけてないだけじゃないのか？ >>312
httpメソッドが何かなんて誰も焦点にあててないのに何で急にPOSTが出てきた？ json_encodeやらjson_decodeって関数名が出てくるのがまずおかしい >>315
いや、curlじゃなくても良いんだけどね。
言語に依存しない点で例に適切だろうからcurlが良いなって思っただけだよ。
で、その場合はaxiosにjavascriptオブジェクトを渡してapplication/jsonをPOSTするのと比べてどう適切（セキュア）なの？ ここまでの流れ
JSONは危険おじさん 「JSONは危険」
何が危険なのおじさん「何が危険なの」
JSONは危険おじさん 「パースする時が危険」
何が危険なのおじさん「何が危険なの」
JSONは危険おじさん 「危険なものは危険」
何が危険なのおじさん「危険な例をだせよ」
JSONは危険おじさん 「普通にPOSTするだけ」 >>320
普通にPOSTするだけ は 何が危険なのおじさん の方だよ >>321
普通にPOSTするだけおじさんは「サーバー→クライアントにしかjsonを使わない」って言ってるよ
例もjsonじゃなかったし でも実際JSONは危険だよね
去年のやつだってJSONの解析処理を逆手にとって
顧客情報盗まれたわけだし そういえばLaravelの次期バージョンでフレームワークによるJSONサポートをなくそうかって話出てるね
多分この案は採用されないだろうけどさ >>325
とりあえずissue見てみたけど見つからん
どこに書いてあるの？ 結局「JSONは危険おじさん」による具体例と代替フォーマット無し ヘッダーとしてAuthorization: Bearerで認証トークンくっつけて送信しろボケナスくんたち >>324
去年の奴ってなんだよw
去年あった大きい事件で言えばセブンペイのパスワードリセットの件か？
JSONは関係無かったが 今はContent-typeにapplication/jsonを指定することの是非を話していて、
Authorizationヘッダは関係無いよ。
それともお前の頭の中ではAuthorizationヘッダにBearerトークンを指定するとなぜか急にJSONのパースがセキュアになんのかよｗ ■ このスレッドは過去ログ倉庫に格納されています
